Værste SQL Nogensinde

Hvad er den værste SQL-forespørgsel, du nogensinde har set? Hvad der gjorde det dårligt?

Måske ønsker at gøre dette til en ef-WIKI, ellers er nogen der vil lukke den ned.
Han har helt sikkert nok rep til at lave sit eget spørgsmål en wiki. Wikify dette.
prøv igen som en wiki.
At fremhæve, hvad der er dårlig programmering praksis handler om programmering (og så meget mere end nogle af de andre slap-0washy emner, jeg har set)
Det er ikke et spørgsmål med et bare tilnærmelsesvis endeligt svar. I stedet er det et spørgsmål, som forventer en masse af gyldige svar. Ergo: wiki.

OriginalForfatteren | 

21 svar

  1. 35
    DELETE FROM table

    Set lige efter jeg har skrevet og udført det, jeg havde glemt, HVOR klausulen. Nu har jeg altid køre en SELECT-sætning, første og ændre VÆLGE at SLETTE, efter at jeg er tilfreds med, at de korrekte rækker vil blive berørt.

    Øv..! Jeg er paranoid, jeg altid omgiver opdatere/slette udsagn med begynder tran/rollback, prøv det og derefter udføre den indre del, når jeg føler mig tryg.
    Jeg gør noget lignende, bortset fra at jeg bare skrive Tabelnavn som TableNameFOO, samtidig med at jeg skaber den. Jeg holder også “Til:” inden for e-mails tom, før jeg skriver det hele e-mail og korrekturlæst… just in case 😉
    Dette var MySQL, før de støttede transaktioner 🙁
    Fyre… vælg * i z_backup fra <vigtigt tabel> som dit første skridt. Så gå hog wild.
    Jeg har gjort dette før, mens de er på arbejde, heldigvis var jeg arbejder på udvikling server, og jeg har lige gendannet den sidste arbejder database backup. Jeg skrev også en web-side for at forvalte uddannelsesmæssige status for medarbejdere for nylig, og til venstre ud, hvor klausulen. Lad os bare sige, at alle har en grad nu.

    OriginalForfatteren

  2. 25

    Den klassiske xkcd selvfølgelig:

    WHERE name = ROBERT'); DROP TABLE students;--
    Hvorfor gjorde du få negative stemmer for dette? Det er vildt sjovt!
    Åh, nogen har fjernet deres negative stemmer.
    Vi kalder ham Lille Bobby Tabeller
    Hvordan er dette betragtes som “værste”? Det er genialt.
    Storhed er ikke det forespørgsel, det er det navn 🙂

    OriginalForfatteren

  3. 13

    Værste BRUGE af en SQL-forespørgsel, hver:

    En SELECT-forespørgsel, der tæller antallet af linjer, der svarer til en bestemt tilstand, som kaldes på at stoppe betingelse af en for-løkke.

    Noget som dette:

    for(int i = 0; i < query("SELECT COUNT .... WHERE ..."); i++)
    {
    
    }

    Og nej, resultatet af søgningen ikke ændres, hver iteration. Ja jeg er klar over serveren kommer til at cache resultatet.

    OriginalForfatteren

  4. 9

    En kunde var lagring af en komma-separeret liste af 3 værdier i en varchar felt (classic ASP applikation), så de havde en lagret procedure, der så noget som dette:

    SELECT *
    FROM
        SomeTable
    WHERE
        Field LIKE @Param + ',%'
        OR
        Field LIKE '%,' + @Param + ',%'
        OR
        Field LIKE '%,' + @Param

    Det bør være indlysende, at det er forfærdeligt 🙂

    ouch! Det gør mine tænder gør ondt!
    Jeg har set lignende ting i en stor produktion program :S
    Er der en bedre måde at skrive dette?
    Ved ikke, hvis bedre er det rigtige ord, men — HVOR ‘,’ + Område + ‘,’ LIKE ‘%,’ + @Param + ‘,%’ — vil sandsynligvis køre hurtigere. Selvfølgelig bør du ikke have kommasepareret data i felter i et RDBMS.

    OriginalForfatteren

  5. 9

    En PL/SQL (Oracle), der er gemt proc der sorteres et resultat, der ved hjælp af en Bubble Form. Det blev opdaget, da jeg og DBA blev bedt om at finde ud af et alvorligt problem med ydeevne. De udvikler en Oracle “ekspert” havde arbejdet på det i over en uge. Han forklarede, med en straight ansigt, at han har lært om den Slags Boble i hans computer science class. Den algoritme, der er almindeligt anvendt til at illustrere dårlige resultater.

    Erstattet det hele rodet med en ORDER BY-delsætning. Performance er forbedret med flere størrelsesordener.

    Der kan være nogle Oracle konsulenter, der ikke er alt for dårligt, men jeg har aldrig mødt en. Jeg arbejdede med en gruppe, hvis Oracle “ekspert” havde skrevet en hel regnskabs-program ved hjælp af “Bat” – filer, som er bundet til tasterne. Således, “I. bat” løb en Faktura form, “R. bat” løb rapporter. Ja, dette var i slutningen af 90’erne.

    OriginalForfatteren

  6. 6
    select * from users where clue > 0;
    0 results found.
    det værste ved denne sql er, at det aldrig returnerer resultaterne, uanset hvor du kører det
    Dette er grunden til, at vi bør være i stand til at upvote kommentarer 🙂
    Hvad sker der, hvorfor du kører denne forespørgsel på Stack Overflow database? Er det stadig return 0 resultater? Eller er det bare tilbage bruger-ID 22656
    Hvorfor er det skidt SQL? Hvorfor spille skyde–messenger?
    Jeg har denne t-shirt.

    OriginalForfatteren

  7. 6

    Min egen, som er alt for længe til at skrive her — lukker nu på 3500 linjer

    Jeg bliver virkelig nødt til at dele skylden med en helt forfærdelig skema. Hvad der startede som en simpel øvelse i drejelige denormalized data ved hjælp af nogle fagforeninger forvandlet til et tungt mareridt. Det er hårdt brug for reparation.

    Runner up er denne:

    select 
    case datepart(mm,getdate())
    when 1 then 'Jan'
    when 2 then 'Feb'
    when 3 then 'March'
    when 4 then 'Apr'
    when 5 then 'May'
    when 6 then 'Jun'
    when 7 then 'July'
    when 8 then 'Aug'
    when 9 then 'Sept'
    when 10 then 'Otc'
    when 11 then 'Nov'
    when 11 then 'Dec'
    end

    Der ikke er nogen stavefejl i et indlæg-det er, hvordan det blev skrevet. Tak, rådgivning dollars!

    Jeg selvfølgelig refactored med at Vælge venstre(datename(mm, getdate()), 3)

    11 kortlagt både til November og December?? Virkelig?
    Vi har opdaget denne perle i December.
    På en arbejdsplads, der forbliver navnløs, dit fix ville faktisk være ildeset, fordi det bryder stavemåde for “September” og “March” (aldrig-husk at det løser en fejl).
    Stavefejl for Oktober…
    fordelen ved denne løsning er, at den ikke påvirkes af locale – så selv fransk, spansk, tysk eller Japansk brugere blive tvunget til at bruge de engelske forkortelser, der for måned navne. 😀

    OriginalForfatteren

  8. 4

    Når jeg først fik mit nuværende job mit første projekt var at skabe et program, der sammenfattet vores licens brug data i vores computer labs. Han insisterede på, at han ikke ønsker backend-database til at blive normaliseret, fordi tiltræder var “for dyrt.” Det er min første uge, jeg var ikke i en position til at argumentere.

    Nu, for at udtrække alle relevante data fra den database, man har for at “fortryde” denormalisering i hver eneste forespørgsel, der skal til at udtrække oversigter for at fjerne duplikerede data i hver række. Selvfølgelig, disse er det eneste spørgsmål, der er faktisk er anvendt. Du kan se en masse af indlejrede vælger at ville være helt unødvendigt, hvis data blev normaliseret, såsom:

    select location, sum(login_time) as total_login_time
    from
        (select location, session_id, max(login_time) as login_time
         from sessions
         where location in ('lab1','lab2') 
               and session_start >= @start_date 
               and session_end <= @end_date
         group by location, session_id) tbl
    group by location

    Selv om forespørgslen i sig selv ikke særligt grimme, selvom nogle er — den proces, der krumspring for hver gang at fortryde unødvendige denormalisering gør ondt.

    Nu chefen er gået, men jeg har ikke tid til at skrive det…

    gøre nogle synspunkter til denormalise data for dig 😀
    Det er bare forkert på så mange niveauer. Især den kommentar om slutter sig at være “alt for dyrt.”

    OriginalForfatteren

  9. 4

    I en udstationering til comp.databaser.informix nyheder gruppe – en ægte arbejder Informix tabel (som jeg ikke anbefale at bruge):

    CREATE TABLE VIEW
    (
        DECIMAL     CHAR(30),
        NOT         INTEGER NOT NULL,
        SERIAL      DATE NOT NULL,
        NULL        CHAR(1) NOT NULL,
        INTEGER     DECIMAL(13,6) NOT NULL
    );

    Det hjælper (marginalt) hvis du ved, at SERIELLE er en type i Informix databaser – dybest set, en af de former for generering af automatisk tildelt numre som serie.

    OriginalForfatteren

  10. 3

    SUBSTRING(
    (SUBSTRING(Efternavn, 0, CHARINDEX(‘ ‘, Efternavn)) + ‘, ‘ + Fornavn),
    0,
    CHARINDEX(‘ ‘, (SUBSTRING(Efternavn, 0, CHARINDEX(‘ ‘, Efternavn)) + ‘, ‘ + Fornavn), LEN(Efternavn) + 3)
    )

    de tilsyneladende ikke var bekendt med RTRIM;

    RTRIM(Efternavn) + ‘, ‘ + RTRIM(Fornavn)

    OriginalForfatteren

  11. 2

    vælg * fra *

    Virkelig dårligt.

    VÆLG * FRA * HVOR * = ‘%%’; jeg vover at check, hvis dette rent faktisk virker.
    eller en cross join mellem to eller flere rimeligt store tabeller.
    cross sammenføjning mellem to store, men smalle borde er ofte en optimal løsning for matchende sæt for eksempel – mange-til-mange-er et fælles problem

    OriginalForfatteren

  12. 2

    Det er nok ikke det værste, men jeg ser det alt for ofte (Misbrug af gruppen af klausulen):

    SELECT
      C.CustomerID, C.CustomerName, C.CustomerType, C.Address1, C.City,   
      C.State, SUM(S.Sales) as TotalSales
    FROM
      Customers C
    INNER JOIN Sales S
      ON C.CustomerID = S.CustomerID
    GROUP BY
      C.CustomerID, C.CustomerName, C.CustomerType, C.Address1, C.City, C.State

    I stedet for:

    SELECT
      C.CustomerID, C.CustomerName,
      C.CustomerType, C.Address1, C.City,
      C.State, S.TotalSales
    FROM
      Customers C
    INNER JOIN
      (SELECT CustomerID, SUM(Sales) as TotalSales FROM Sales GROUP BY CustomerID) S
    ON
      C.CustomerID = S.CustomerID
    ring til mig på dette er, at du vil men jeg er uenig i, at en regel om, at 1 er dårligt og 2 er god. Med et mere komplekst eksempel 2 bliver en hel del sværere at opretholde. For mig, hvor 1 er meget klar i sin hensigt og hertil, som er nemmere at vedligeholde. 2, kan tilbyde en bedre ydeevne, men gevinsten kan ikke være det værd.
    Også, regel 2 er langsommere under mysql. mysql–. sidstnævnte er endnu mere at vedligeholde, hvis du adskille det og bruge string-substitution til at komponere den sidste forespørgsel. INNER JOIN ( $customerTotals ) 😀
    Vil der ikke være en ekstra deltage med syntaks 2? Måske eller måske ikke noget
    +1 for den interessante refactoring – god pointe. Version 1 er en simpel pre-SQL-92-forespørgsel, der er tilpasset til at bruge SQL-92 deltage i-notation. Den anden bør ikke være langsommere – det gør det gruppering på et enkelt bord, og så slutter det med den oprindelige (medmindre, jeg formoder, de optimizer ikke for sub-forespørgsel resultat, og udnytte, at orden i flet sammen med kunde-tabellen, i hvilket tilfælde det kunne være langsommere end en indekseret deltage).

    OriginalForfatteren

  13. 2

    Jeg tror, dette er det værste (især efterfulgt af en smertefuld og null rollback):

    DROP DATABASE;
    ROLLBACK;

    OriginalForfatteren

  14. 2

    læse det højt.

    select [select],*,star as [as] from [from],[order] order by [by] 
    Er der formodes at være noget i retning af slashdot.org

    OriginalForfatteren

  15. 1

    For nylig, jeg har set en (større end) 4000 linje TSQL en lagret procedure, der var en kæde af HVIS statments til at matche dele af adresser. Det kunne være reduceret til mindre end 50 linjer!

    Jeg gemmer koden for en fremtidig DailyWTF!

    OriginalForfatteren

  16. 1
    SELECT * FROM some_table;

    Hvad der har gjort det så dårligt, var den kode, der var afhængige af at få de resultater i orden baseret på et tidsstempel. Dette havde tilsyneladende arbejdede for et stykke tid, før jeg fik kaldt ind for at løse det.

    OriginalForfatteren

  17. 1

    I en Access-Database, der var en forespørgsel, som følgende:

    SELECT *
    FROM Bad_2 INNER JOIN Bad_1 ON Bad_2.Bad_1_id = Bad_1.ID;

    og begge borde var et felt med samme navn. Når Adgangen kommer på tværs af et område navn til en anden gang, det gør op for et nyt navn for den. Den tidligere fyr, anvendes det felt, der genereres navn i koden.

    OriginalForfatteren

  18. 1

    Set mange sørgelige stykker af SQL-i min tid.
    En, der kommer til at tænke på er i form

    indlæse data fra en fil, loop over denne fil, og få adgang til db for hver linje i filen.

    Virker ok på test-systemer med 10 eller deromkring linjer, 100K-1 mio = grim selv for primære
    nøglen opslag.

    BTW, løsningen er at indlæse data i db og tænke i sæt.

    — Vælg din favorit lang f.eks. perl, python …

    indlæse en fil til datastrukturen (f.eks array)


    for (1 .. n) loop
    myid := array[n];
    select * from table where id = myid;
    if the row exists update table set ... where id = myid;
    end loop;

    OriginalForfatteren

  19. 0

    SLETTE FRA some_table HVOR some_thing I (VÆLG some_column_from_wrong_table FRA correct_table HVOR et_id=noget).

    Den some_column_from_wrong_table har en kolonne, der var ikke engang i tabellen, men det var i en anden tabel.
    Problemet var correct_table blev navngivet ‘Event’, og på en eller anden måde vendte ALLE rækker i stedet for at INGEN rækker (eller endnu vigtigere, en fejl!).

    To erfaringer: ALDRIG NOGENSINDE, under nogen omstændigheder, navn et bord efter nogen form af systemets navn. Anden ting var at køre select-sætninger først, derefter skifte til at slette.

    Dette var SqlServer 2005 ved den måde. Jeg er stadig pissed det ikke smide en fejl.

    OriginalForfatteren

  20. 0

    Jeg kunne godt lide den ene reposted for nylig på dailywtf, den historie, der kommer med det er fantastisk så godt.

    OriginalForfatteren

  21. -1
    SELECT name FROM categories WHERE id IN (".implode(",",corrected_cats($ad->id)).") ORDER BY name ASC

    Ja, du læser rigtigt… kommaseparerede felter i et område.

    OriginalForfatteren

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *