Was sind die häufigsten SQL-Anti-Patterns? [geschlossen]

Alle von uns, die mit relationalen Datenbanken arbeiten, haben gelernt (oder lernen), dass SQL anders ist. Um die gewünschten Ergebnisse zu erzielen und dies effizient zu tun, ist ein langwieriger Prozess erforderlich, der teilweise durch das Erlernen unbekannter Paradigmen gekennzeichnet ist und herausfindet, dass einige unserer bekanntesten Programmiermuster hier nicht funktionieren. Was sind die häufigsten Antimuster, die Sie gesehen haben (oder die Sie selbst begangen haben)?

Ich bin immer wieder enttäuscht von der Tendenz der meisten Programmierer, ihre UI-Logik in der Datenzugriffsschicht zu mischen:

SELECT
    FirstName + ' ' + LastName as "Full Name",
    case UserRole
        when 2 then "Admin"
        when 1 then "Moderator"
        else "User"
    end as "User's Role",
    case SignedIn
        when 0 then "Logged in"
        else "Logged out"
    end as "User signed in?",
    Convert(varchar(100), LastSignOn, 101) as "Last Sign On",
    DateDiff('d', LastSignOn, getDate()) as "Days since last sign on",
    AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' +
        City + ', ' + State + ' ' + Zip as "Address",
    'XXX-XX-' + Substring(
        Convert(varchar(9), SSN), 6, 4) as "Social Security #"
FROM Users

Normalerweise tun dies Programmierer, weil sie beabsichtigen, ihr Dataset direkt an ein Raster zu binden, und es ist einfach praktisch, das SQL Server-Format serverseitig als das Format auf dem Client zu haben.

Abfragen wie die oben gezeigte sind extrem spröde, da sie die Datenschicht eng mit der UI-Schicht koppeln. Darüber hinaus verhindert diese Art der Programmierung gründlich, dass gespeicherte Prozeduren wiederverwendbar sind.

Hier sind meine Top 3.

Nummer 1. Keine Angabe einer Feldliste. (Bearbeiten: Um Verwirrung zu vermeiden: Dies ist eine Produktionscode-Regel. Sie gilt nicht für einmalige Analyseskripte - es sei denn, ich bin der Autor.)

SELECT *
Insert Into blah SELECT *

sollte sein

SELECT fieldlist
Insert Into blah (fieldlist) SELECT fieldlist

Nummer 2. Verwenden eines Cursors und einer while-Schleife, wenn eine while-Schleife mit einer Schleifenvariablen ausreicht.

DECLARE @LoopVar int

SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable)
WHILE @LoopVar is not null
BEGIN
  -- Do Stuff with current value of @LoopVar
  ...
  --Ok, done, now get the next value
  SET @LoopVar = (SELECT MIN(TheKey) FROM TheTable
    WHERE @LoopVar < TheKey)
END

Nummer 3. DateLogic durch Zeichenfolgentypen.

--Trim the time
Convert(Convert(theDate, varchar(10), 121), datetime)

Sollte sein

--Trim the time
DateAdd(dd, DateDiff(dd, 0, theDate), 0)

Ich habe kürzlich einen Anstieg von "Eine Abfrage ist besser als zwei, oder?" Gesehen.

SELECT *
FROM blah
WHERE (blah.Name = @name OR @name is null)
  AND (blah.Purpose = @Purpose OR @Purpose is null)

Diese Abfrage erfordert zwei oder drei verschiedene Ausführungspläne, abhängig von den Werten der Parameter. Für diesen SQL-Text wird nur ein Ausführungsplan generiert und im Cache gespeichert. Dieser Plan wird unabhängig vom Wert der Parameter verwendet. Dies führt zu einer zeitweise schlechten Leistung. Es ist viel besser, zwei Abfragen zu schreiben (eine Abfrage pro beabsichtigtem Ausführungsplan).

• Vom Menschen lesbare Passwortfelder , z. Selbsterklärend.

• Verwenden von LIKE für indizierte Spalten, und ich bin fast versucht, nur LIKE im Allgemeinen zu sagen.

• Recycling von SQL-generierten PK-Werten.

• Überraschung, dass noch niemand den Gott-Tisch erwähnt hat. Nichts sagt "organisch" wie 100 Spalten mit Bitflags, großen Strings und ganzen Zahlen.

• Dann gibt es das Muster "Ich vermisse INI-Dateien" : Speichern von CSVs, durch Pipe getrennten Zeichenfolgen oder anderen analysierten erforderlichen Daten in großen Textfeldern.

• Und für MS SQL Server die Verwendung von Cursorn überhaupt . Es gibt eine bessere Möglichkeit, eine bestimmte Cursoraufgabe auszuführen.

Bearbeitet, weil es so viele gibt!

Sie müssen nicht tief graben: Verwenden Sie keine vorbereiteten Anweisungen.

Verwenden bedeutungsloser Tabellen-Aliase:

from employee t1,
department t2,
job t3,
...

Das Lesen einer großen SQL-Anweisung wird so viel schwieriger als nötig

var query = "select COUNT(*) from Users where UserName = '" 
            + tbUser.Text 
            + "' and Password = '" 
            + tbPassword.Text +"'";

1. Benutzereingaben blind vertrauen
2. Keine parametrisierten Abfragen verwenden
3. Klartext-Passwörter

Meine Bugbears sind die 450-Spalten-Zugriffstabellen, die vom 8-jährigen Sohn des Hundefreundes des besten Freundes des Geschäftsführers zusammengestellt wurden, und die zwielichtige Nachschlagetabelle, die nur existiert, weil jemand nicht weiß, wie man eine Datenstruktur richtig normalisiert.

In der Regel sieht diese Nachschlagetabelle folgendermaßen aus:

ID INT,
Name NVARCHAR (132),
IntValue1 INT,
IntValue2 INT,
CharValue1 NVARCHAR (255),
CharValue2 NVARCHAR (255),
Datum1 DATETIME,
Datum2 DATETIME

Ich habe die Anzahl der Kunden verloren, die Systeme gesehen haben, die auf solchen Greueln beruhen.

Diejenigen, die ich am wenigsten mag, sind

1. Verwenden von Leerzeichen beim Erstellen von Tabellen, Sprocs usw. Ich bin mit CamelCase oder under_scores und Singular oder Plural und Großbuchstaben oder Kleinbuchstaben einverstanden, muss mich aber auf eine Tabelle oder Spalte [mit Leerzeichen] beziehen, insbesondere wenn [sie einen merkwürdigen Abstand hat] (ja, Ich bin darauf gestoßen) irritiert mich wirklich.

2. Denormalisierte Daten. Eine Tabelle muss nicht perfekt normalisiert sein, aber wenn ich auf eine Tabelle mit Mitarbeitern stoße, die Informationen über ihre aktuelle Bewertungspunktzahl oder ihre primären Daten enthält, muss ich wahrscheinlich irgendwann eine separate Tabelle erstellen Versuchen Sie dann, sie synchron zu halten. Ich werde zuerst die Daten normalisieren und dann, wenn ich einen Ort sehe, an dem die Denormalisierung hilft, werde ich darüber nachdenken.

3. Überbeanspruchung von Ansichten oder Cursorn. Ansichten haben einen Zweck, aber wenn jede Tabelle in eine Ansicht eingeschlossen ist, ist es zu viel. Ich musste einige Male Cursor verwenden, aber im Allgemeinen können Sie dafür andere Mechanismen verwenden.

4. Zugriff. Kann ein Programm ein Anti-Pattern sein? Wir haben SQL Server in meiner Arbeit, aber eine Reihe von Personen verwenden den Zugriff aufgrund seiner Verfügbarkeit, "Benutzerfreundlichkeit" und "Freundlichkeit" für nicht technische Benutzer. Es gibt hier zu viel, um darauf einzugehen, aber wenn Sie in einer ähnlichen Umgebung waren, wissen Sie.

Verwenden Sie SP als Präfix für den Namen der Speicherprozedur, da diese zuerst am Speicherort der Systemprozeduren und nicht an den benutzerdefinierten suchen.

Überbeanspruchung temporärer Tabellen und Cursor.

Zum Speichern von Zeitwerten sollte nur die UTC-Zeitzone verwendet werden. Ortszeit sollte nicht verwendet werden.

Verwenden von @@ IDENTITY anstelle von SCOPE_IDENTITY ()

Zitiert aus dieser Antwort :

• @@ IDENTITY gibt den letzten Identitätswert zurück, der für eine Tabelle in der aktuellen Sitzung in allen Bereichen generiert wurde. Sie müssen hier vorsichtig sein, da es sich um Bereiche handelt. Sie könnten anstelle Ihrer aktuellen Anweisung einen Wert von einem Trigger erhalten.
• SCOPE_IDENTITY gibt den letzten Identitätswert zurück, der für eine Tabelle in der aktuellen Sitzung und im aktuellen Bereich generiert wurde. Im Allgemeinen, was Sie verwenden möchten.
• IDENT_CURRENT gibt den letzten Identitätswert zurück, der für eine bestimmte Tabelle in einer Sitzung und einem Bereich generiert wurde. Auf diese Weise können Sie angeben, aus welcher Tabelle der Wert stammen soll, falls die beiden oben genannten nicht ganz Ihren Anforderungen entsprechen (sehr selten). Sie können dies verwenden, wenn Sie den aktuellen IDENTITY-Wert für eine Tabelle abrufen möchten, in die Sie keinen Datensatz eingefügt haben.

Wiederverwendung eines "toten" Felds für etwas, für das es nicht vorgesehen war (z. B. Speichern von Benutzerdaten in einem "Fax" -Feld) - sehr verlockend als schnelle Lösung!

select some_column, ...
from some_table
group by some_column

und unter der Annahme, dass das Ergebnis nach some_column sortiert wird. Ich habe dies ein bisschen bei Sybase gesehen, wo die Annahme (vorerst) gilt.

SELECT FirstName + ' ' + LastName as "Full Name", case UserRole when 2 then "Admin" when 1 then "Moderator" else "User" end as "User's Role", case SignedIn when 0 then "Logged in" else "Logged out" end as "User signed in?", Convert(varchar(100), LastSignOn, 101) as "Last Sign On", DateDiff('d', LastSignOn, getDate()) as "Days since last sign on", AddrLine1 + ' ' + AddrLine2 + ' ' + AddrLine3 + ' ' + City + ', ' + State + ' ' + Zip as "Address", 'XXX-XX-' + Substring(Convert(varchar(9), SSN), 6, 4) as "Social Security #" FROM Users

Oder alles in eine Zeile packen.

• Die FROM TableA, TableB WHERESyntax für JOINS anstattFROM TableA INNER JOIN TableB ON

• Die Annahme, dass eine Abfrage zurückgegeben wird, wird auf eine bestimmte Weise sortiert, ohne dass eine ORDER BY-Klausel eingefügt wird, nur weil dies beim Testen im Abfragetool so angezeigt wurde.

In den ersten sechs Monaten ihrer Karriere SQL lernen und in den nächsten 10 Jahren nichts anderes lernen. Insbesondere nicht lernen oder Fensterfunktionen / analytische SQL-Funktionen effektiv nutzen. Insbesondere die Verwendung von over () und Partitionierung durch.

Fensterfunktionen führen wie Aggregatfunktionen eine Aggregation für eine definierte Menge (eine Gruppe) von Zeilen durch. Anstatt jedoch einen Wert pro Gruppe zurückzugeben, können Fensterfunktionen mehrere Werte für jede Gruppe zurückgeben.

In O'Reilly SQL Cookbook Anhang A finden Sie eine schöne Übersicht über die Fensterfunktionen.

Ich muss hier meinen eigenen aktuellen Favoriten eintragen, um die Liste zu vervollständigen. Mein Lieblings-Antimuster testet Ihre Fragen nicht .

Dies gilt, wenn:

1. Ihre Anfrage umfasst mehr als eine Tabelle.
2. Sie denken, Sie haben ein optimales Design für eine Abfrage, aber Sie müssen Ihre Annahmen nicht testen.
3. Sie akzeptieren die erste Abfrage, die funktioniert, ohne eine Ahnung zu haben, ob sie überhaupt optimiert ist.

Und Tests, die gegen atypische oder unzureichende Daten durchgeführt werden, zählen nicht. Wenn es sich um eine gespeicherte Prozedur handelt, fügen Sie die Testanweisung in einen Kommentar ein und speichern Sie sie mit den Ergebnissen. Andernfalls fügen Sie es in einen Kommentar im Code mit den Ergebnissen ein.

Vorübergehender Tischmissbrauch.

Speziell so etwas:

SELECT personid, firstname, lastname, age
INTO #tmpPeople
FROM People
WHERE lastname like 's%'

DELETE FROM #tmpPeople
WHERE firstname = 'John'

DELETE FROM #tmpPeople
WHERE firstname = 'Jon'

DELETE FROM #tmpPeople
WHERE age > 35

UPDATE People
SET firstname = 'Fred'
WHERE personid IN (SELECT personid from #tmpPeople)

Erstellen Sie keine temporäre Tabelle aus einer Abfrage, nur um die nicht benötigten Zeilen zu löschen.

Und ja, ich habe Codeseiten in dieser Form in Produktions-DBs gesehen.

Gegenteilige Ansicht: Überbesessenheit mit Normalisierung.

Die meisten SQL / RBDB-Systeme bieten eine Reihe von Funktionen (Transaktionen, Replikation), die selbst bei nicht normalisierten Daten sehr nützlich sind. Der Speicherplatz ist billig und manchmal kann es einfacher (einfacherer Code, schnellere Entwicklungszeit) sein, abgerufene Daten zu bearbeiten / filtern / durchsuchen, als ein 1NF-Schema zu schreiben und alle darin enthaltenen Probleme zu lösen (komplexe Verknüpfungen, unangenehme Unterauswahlen) , etc).

Ich habe festgestellt, dass die übernormalisierten Systeme häufig vorzeitig optimiert werden, insbesondere in frühen Entwicklungsphasen.

(Weitere Gedanken dazu ... http://writeonly.wordpress.com/2008/12/05/simple-object-db-using-json-and-python-sqlite/ )

Ich habe gerade diese zusammengestellt, basierend auf einigen der SQL-Antworten hier auf SO.

Es ist ein ernstes Gegenmuster zu glauben, dass Trigger für Datenbanken gelten, wie Event-Handler für OOP. Es gibt diese Wahrnehmung, dass nur jede alte Logik in Trigger gesetzt werden kann, um ausgelöst zu werden, wenn eine Transaktion (ein Ereignis) auf einem Tisch stattfindet.

Nicht wahr. Einer der großen Unterschiede besteht darin, dass Trigger synchron sind - mit aller Macht, weil sie bei einer festgelegten Operation und nicht bei einer Zeilenoperation synchron sind. Auf der OOP-Seite ist genau das Gegenteil der Fall - Ereignisse sind eine effiziente Möglichkeit, asynchrone Transaktionen zu implementieren.

Gespeicherte Prozeduren oder Funktionen ohne Kommentare ...

1) Ich weiß nicht, dass es sich um ein "offizielles" Anti-Pattern handelt, aber ich mag es nicht und versuche, String-Literale als magische Werte in einer Datenbankspalte zu vermeiden.

Ein Beispiel aus MediaWikis Tabelle 'image':

img_media_type ENUM("UNKNOWN", "BITMAP", "DRAWING", "AUDIO", "VIDEO", 
    "MULTIMEDIA", "OFFICE", "TEXT", "EXECUTABLE", "ARCHIVE") default NULL,
img_major_mime ENUM("unknown", "application", "audio", "image", "text", 
    "video", "message", "model", "multipart") NOT NULL default "unknown",

(Ich bemerke nur ein anderes Gehäuse, eine andere Sache, die man vermeiden sollte)

Ich entwerfe solche Fälle wie int-Lookups in Tabellen ImageMediaType und ImageMajorMime mit int-Primärschlüsseln.

2) Datums- / Zeichenfolgenkonvertierung, die auf bestimmten NLS-Einstellungen basiert

CONVERT(NVARCHAR, GETDATE())

ohne Formatkennung

Identische Unterabfragen in einer Abfrage.

• Die geänderte Ansicht - Eine Ansicht, die zu oft und ohne Vorankündigung oder Grund geändert wird. Die Änderung wird entweder zum unangemessensten Zeitpunkt bemerkt oder ist schlimmer noch falsch und wird nie bemerkt. Möglicherweise wird Ihre Anwendung unterbrochen, weil sich jemand einen besseren Namen für diese Spalte ausgedacht hat. In der Regel sollten Ansichten den Nutzen von Basistabellen erweitern und gleichzeitig einen Vertrag mit Verbrauchern aufrechterhalten. Beheben Sie Probleme, fügen Sie jedoch keine Funktionen hinzu oder ändern Sie das Verhalten nicht. Erstellen Sie dazu eine neue Ansicht. Um dies zu verringern, teilen Sie keine Ansichten mit anderen Projekten und verwenden Sie CTEs, wenn die Plattformen dies zulassen. Wenn Ihr Shop über einen DBA verfügt, können Sie die Ansichten wahrscheinlich nicht ändern, aber alle Ihre Ansichten sind veraltet und in diesem Fall unbrauchbar.

• The! Paramed - Kann eine Abfrage mehr als einen Zweck haben? Wahrscheinlich, aber die nächste Person, die es liest, wird es erst in tiefer Meditation wissen. Selbst wenn Sie sie gerade nicht brauchen, werden Sie es wahrscheinlich tun, auch wenn es "nur" zum Debuggen ist. Das Hinzufügen von Parametern verkürzt die Wartungszeit und hält die Dinge trocken. Wenn Sie eine where-Klausel haben, sollten Sie Parameter haben.

• Der Fall für keinen Fall -

  SELECT  
  CASE @problem  
    WHEN 'Need to replace column A with this medium to large collection of strings hanging out in my code.'  
      THEN 'Create a table for lookup and add to your from clause.'  
    WHEN 'Scrubbing values in the result set based on some business rules.'  
      THEN 'Fix the data in the database'  
    WHEN 'Formating dates or numbers.'   
      THEN 'Apply formating in the presentation layer.'  
    WHEN 'Createing a cross tab'  
      THEN 'Good, but in reporting you should probably be using cross tab, matrix or pivot templates'   
  ELSE 'You probably found another case for no CASE but now I have to edit my code instead of enriching the data...' END  

Die beiden, die ich am meisten finde und die erhebliche Kosten in Bezug auf die Leistung verursachen können, sind:

• Verwenden von Cursorn anstelle eines satzbasierten Ausdrucks. Ich denke, dies tritt häufig auf, wenn der Programmierer prozedural denkt.

• Verwenden von korrelierten Unterabfragen, wenn ein Join zu einer abgeleiteten Tabelle die Aufgabe übernehmen kann.

Das Einfügen von Inhalten in temporäre Tabellen, insbesondere von Personen, die von SQL Server zu Oracle wechseln, hat die Angewohnheit, temporäre Tabellen zu häufig zu verwenden. Verwenden Sie einfach verschachtelte select-Anweisungen.

Entwickler, die Abfragen schreiben, ohne eine gute Vorstellung davon zu haben, was SQL-Anwendungen (sowohl einzelne Abfragen als auch Mehrbenutzersysteme) schnell oder langsam macht. Dies beinhaltet Unwissenheit über:

• Strategien zur Minimierung der physischen E / A, da der Engpass bei den meisten Abfragen die E / A und nicht die CPU ist
• Perfekte Auswirkung verschiedener Arten des physischen Speicherzugriffs (z. B. sind viele sequentielle E / A schneller als viele kleine zufällige E / A, wenn auch weniger, wenn es sich bei Ihrem physischen Speicher um eine SSD handelt!)
• So optimieren Sie eine Abfrage von Hand, wenn das DBMS einen schlechten Abfrageplan erstellt
• wie man eine schlechte Datenbankleistung diagnostiziert, wie man eine langsame Abfrage "debuggt" und wie man einen Abfrageplan liest (oder EXPLAIN, abhängig von dem DBMS Ihrer Wahl)
• Sperrstrategien zur Optimierung des Durchsatzes und zur Vermeidung von Deadlocks in Mehrbenutzeranwendungen
• Wichtigkeit von Batching und anderen Tricks für die Verarbeitung von Datensätzen
• Tabellen- und Indexdesign, um Speicherplatz und Leistung optimal in Einklang zu bringen (z. B. Indizes abdecken, Indizes möglichst klein halten, Datentypen auf die erforderliche Mindestgröße reduzieren usw.)

Verwenden von SQL als verherrlichtes ISAM-Paket (Indexed Sequential Access Method). Insbesondere das Verschachteln von Cursorn anstelle der Kombination von SQL-Anweisungen zu einer einzigen, wenn auch größeren Anweisung. Dies gilt auch als "Missbrauch des Optimierers", da der Optimierer tatsächlich nicht viel tun kann. Dies kann mit nicht vorbereiteten Aussagen kombiniert werden, um maximale Ineffizienz zu erzielen:

DECLARE c1 CURSOR FOR SELECT Col1, Col2, Col3 FROM Table1

FOREACH c1 INTO a.col1, a.col2, a.col3
    DECLARE c2 CURSOR FOR
        SELECT Item1, Item2, Item3
            FROM Table2
            WHERE Table2.Item1 = a.col2
    FOREACH c2 INTO b.item1, b.item2, b.item3
        ...process data from records a and b...
    END FOREACH
END FOREACH

Die richtige Lösung besteht (fast immer) darin, die beiden SELECT-Anweisungen zu einer zu kombinieren:

DECLARE c1 CURSOR FOR
    SELECT Col1, Col2, Col3, Item1, Item2, Item3
        FROM Table1, Table2
        WHERE Table2.Item1 = Table1.Col2
        -- ORDER BY Table1.Col1, Table2.Item1

FOREACH c1 INTO a.col1, a.col2, a.col3, b.item1, b.item2, b.item3
    ...process data from records a and b...
END FOREACH

Der einzige Vorteil der Doppelschleifenversion besteht darin, dass Sie die Unterbrechungen zwischen den Werten in Tabelle 1 leicht erkennen können, da die innere Schleife endet. Dies kann ein Faktor in Kontrollunterbrechungsberichten sein.

Außerdem ist das Sortieren in der Anwendung normalerweise ein Nein-Nein.

Verwenden von Primärschlüsseln als Ersatz für Datensatzadressen und Verwenden von Fremdschlüsseln als Ersatz für in Datensätze eingebettete Zeiger.