Direkt nachdem ich getippt und ausgeführt habe, habe ich die WHERE-Klausel vergessen. Jetzt führe ich immer zuerst eine SELECT-Anweisung aus und ändere die SELECT-Anweisung in DELETE, nachdem ich davon überzeugt bin, dass die richtigen Zeilen betroffen sind.
Worst USE einer SQL-Abfrage alle:
Eine SELECT-Abfrage, die die Anzahl der Zeilen zählt, die einer bestimmten Bedingung entsprechen, die in der Stoppbedingung einer for-Schleife aufgerufen wird.
Etwas wie das:
Und nein, das Ergebnis der Abfrage ändert sich nicht bei jeder Iteration. Ja, ich weiß, dass der Server das Ergebnis zwischenspeichern wird.
Ein Kunde hat eine durch Kommas getrennte Liste von 3 Werten in einem varchar-Feld (klassische ASP-Anwendung) gespeichert, so dass sie eine gespeicherte Prozedur hatten, die ungefähr so aussah:
%Vor%Es sollte offensichtlich sein, warum es schrecklich ist:)
Eine PL / SQL (Oracle) gespeicherte Prozedur, die eine Ergebnismenge mit Hilfe einer Bubble-Sortierung sortierte. Es wurde entdeckt, als ich und die DBA gebeten wurden, ein ernsthaftes Leistungsproblem zu lösen. Der Entwickler, ein Oracle "Experte", hatte über eine Woche daran gearbeitet. Er erklärte geradeheraus, dass er in seinem Informatikkurs über Bubble Sort gelernt habe. Der Algorithmus wird häufig verwendet, um eine schlechte Leistung zu veranschaulichen.
Ersetzt das ganze Chaos durch eine ORDER BY-Klausel. Leistung verbessert sich um mehrere Größenordnungen.
Mein eigenes, das ist viel zu lange hier zu schreiben - Schließen jetzt auf 3500 Zeilen
Ich muss wirklich die Schuld mit einem absolut schrecklichen Schema teilen. Was als einfache Übung begann, mit Hilfe einiger Gewerkschaften denormalisierte Daten zu pivotieren, wurde zu einem unhandlichen Albtraum. Es ist dringend reparaturbedürftig.
Runner up ist das:
%Vor%Es gibt keine Tippfehler in diesem Beitrag - so wurde es geschrieben. Danke, Dollars konsultieren!
Ich habe natürlich mit Select links (Datumsname (mm, getdate ()), 3)
refaktoriertAls ich meinen jetzigen Job bekam, war mein erstes Projekt, eine Anwendung zu erstellen, die unsere Lizenznutzungsdaten in unseren Computerlaboren zusammenfasste. Er bestand darauf, dass er nicht wollte, dass die Backend-Datenbank normalisiert wurde, weil Joins "zu teuer" waren. Da ich meine erste Woche war, war ich nicht in der Position zu streiten.
Um nun nützliche Daten aus der Datenbank zu extrahieren, muss die Denormalisierung in jeder Abfrage, die Zusammenfassungen extrahieren muss, um die doppelten Daten in jeder Zeile zu entfernen, rückgängig gemacht werden. Natürlich sind dies die einzigen Abfragen, die tatsächlich verwendet werden. Sie sehen viele verschachtelte Selects, die völlig unnötig wären, wenn die Daten normalisiert wären, wie zum Beispiel:
%Vor%Obwohl die Abfrage selbst nicht besonders hässlich ist - obwohl einige - der Prozess, jedes Mal durch Reifen springen zu müssen, um die unnötige Denormalisierung rückgängig zu machen, schmerzt.
Jetzt ist der Chef weg, aber ich habe keine Zeit, es umzuschreiben ...
Bei einer Veröffentlichung im comp.databases.informix Nachrichtengruppe - eine echte funktionierende Informix-Tabelle (die ich nicht empfehlen werde):
%Vor%Es hilft (marginal), wenn Sie wissen, dass SERIAL ein Typ in Informix-Datenbanken ist - im Grunde einer der Typen, um automatisch zugeordnete Nummern seriell zu generieren.
SUBSTRING ( (SUBSTRING (Nachname, 0, CHARINDEX ('', Nachname)) + ',' + Vorname), 0, CHARINDEX ('', (SUBSTRING (Nachname, 0, CHARINDEX ('', Nachname)) + ',' + Vorname), LEN (Nachname) + 3) )
sie waren anscheinend nicht mit RTRIM vertraut;
RTRIM (Nachname) + ',' + RTRIM (Vorname)
Es ist wahrscheinlich nicht das Schlimmste, aber ich sehe das viel zu oft ( Missbrauch der Gruppenklausel ):
%Vor%Anstelle von:
%Vor%Kürzlich habe ich eine (mehr als) 4000-Zeilen-TSQL-gespeicherte Prozedur gesehen, die eine Kette von IF-Statements für übereinstimmende Teile von Adressen war. Es könnte auf weniger als 50 Zeilen reduziert werden!
Ich speichere den Code für einen zukünftigen DailyWTF!
In einer Access-Datenbank gab es eine Abfrage wie die folgende:
%Vor%und beide Tabellen hatten ein Feld mit dem gleichen Namen. Wenn Access zum zweiten Mal auf einen Feldnamen stößt, wird daraus ein neuer Name. Der vorherige Typ hat den generierten Feldnamen im Code verwendet.
Ich habe in meiner Zeit viele traurige Teile von SQL gesehen. Man denke an die Form
Laden Sie Daten aus einer Datei, durchlaufen Sie diese Datei und greifen Sie auf db für jede Zeile in der Datei zu.
Scheint in Ordnung auf Testsystemen mit 10 oder so Linien, 100K-1million = böse sogar für Primär Schlüsselsuchen.
BTW, die Lösung ist, die Daten in die Datenbank zu laden und in Mengen zu denken.
- Wählen Sie Ihre Lieblingssprache aus. Perl, Python ...
Datei in Datenstruktur laden (zB 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;
DELETE FROM some_table WHERE something IN (SELECT some_column_from_wrong_table FROM correct_table WHERE some_id = etwas).
Die Spalte some_column_from_wrong_table hat eine Spalte, die nicht einmal in der Tabelle war, aber sie war in einer anderen Tabelle. Problem war, dass die correct_table "Event" genannt wurde und irgendwie ALLE Zeilen anstelle von NO Zeilen (oder noch wichtiger, ein Fehler!) Zurückgegeben hat.
Zwei Lektionen gelernt: NIEMALS, Nennen Sie niemals eine Tabelle nach irgendeiner Form des Systemnamens. Zweite Sache war, zuerst Anweisungen ausführen, dann ändern, um zu löschen.
Das war SqlServer 2005 übrigens. Ich bin immer noch sauer, es hat keinen Fehler geworfen.
Ich mochte den kürzlich geposteten auf dem dailywtf, dem die Geschichte, die damit einhergeht, ist auch wundervoll.
Ja, Sie lesen das richtig ... durch Komma getrennte Felder in einem Feld.