Fehler bei der Datenbankentwicklung, die von Anwendungsentwicklern gemacht werden

Question

Was sind häufige Fehler bei der Datenbankentwicklung, die von Anwendungsentwicklern gemacht werden?

Answer 1

Verwendung von Excel zur Speicherung von (großen) Datenmengen.

Ich habe Unternehmen gesehen, die Tausende von Zeilen haben und mehrere Arbeitsblätter verwenden (aufgrund der Zeilenbegrenzung von 65535 in früheren Excel-Versionen).

---

Excel eignet sich gut für Berichte, Datenpräsentationen und andere Aufgaben, sollte aber nicht als Datenbank behandelt werden.

Answer 2

Ich möchte noch etwas hinzufügen: Die Bevorzugung von "elegantem" Code gegenüber hochleistungsfähigem Code. Der Code, der am besten mit Datenbanken funktioniert, ist in den Augen des Anwendungsentwicklers oft hässlich.

Diesen Unsinn über die vorzeitige Optimierung zu glauben. Datenbanken müssen beim ursprünglichen Entwurf und bei jeder nachfolgenden Entwicklung die Leistung berücksichtigen. Meiner Meinung nach macht die Leistung 50 % des Datenbankentwurfs aus (40 % sind Datenintegrität und die letzten 10 % sind Sicherheit). Datenbanken, die nicht von Grund auf auf Leistung ausgelegt sind, werden schlecht funktionieren, sobald echte Benutzer und echter Datenverkehr auf die Datenbank zugreifen. Verfrühte Optimierung bedeutet nicht, dass keine Optimierung stattfindet! Es bedeutet nicht, dass Sie Code schreiben sollten, der fast immer schlecht funktionieren wird, weil Sie es einfacher finden (z. B. Cursor, die in einer Produktionsdatenbank niemals erlaubt sein sollten, wenn nicht alles andere versagt hat). Es bedeutet, dass Sie das letzte Quäntchen Leistung erst dann herausquetschen sollten, wenn es nötig ist. Es ist viel darüber bekannt, was bei Datenbanken besser funktioniert. Dies bei der Konzeption und Entwicklung zu ignorieren, ist bestenfalls kurzsichtig.

Answer 3

Keine parametrisierten Abfragen verwenden. Sie sind ziemlich praktisch beim Stoppen von SQL-Einschleusung .

Dies ist ein konkretes Beispiel dafür, dass Eingabedaten nicht bereinigt werden, wie in einer anderen Antwort erwähnt.

Answer 4

Für SQL-basierte Datenbanken:

1. Nichtausnutzung der Vorteile von CLUSTERED INDEXES oder Auswahl der falschen Spalte(n) für CLUSTER.
2. Keine Verwendung eines SERIAL (Autonummer)-Datentyps als PRIMARY KEY zur Verknüpfung mit einem FOREIGN KEY (INT) in einer Eltern/Kind-Tabellenbeziehung.
3. Keine Aktualisierung der Statistiken einer Tabelle, wenn viele Datensätze EINGESETZT oder GELÖSCHT wurden.
4. Tabellen nicht reorganisieren (d.h. entladen, löschen, neu erstellen, laden und neu indizieren), wenn viele Zeilen eingefügt oder gelöscht wurden (einige Engines behalten gelöschte Zeilen physisch in einer Tabelle mit einer Löschmarkierung).
5. Keine Nutzung der Vorteile von FRAGMENT ON EXPRESSION (falls unterstützt) bei großen Tabellen mit hohen Transaktionsraten.
6. Auswahl des falschen Datentyps für eine Spalte!
7. Keine richtige Spaltenbezeichnung gewählt.
8. Keine neuen Spalten am Ende der Tabelle hinzufügen.
9. Keine Erstellung geeigneter Indizes zur Unterstützung häufig verwendeter Abfragen.
10. Erstellung von Indizes für Spalten mit wenigen möglichen Werten und Erstellung unnötiger Indizes.
    ...weitere werden hinzugefügt.

Answer 5

Ich hasse es, wenn Entwickler verschachtelte Select-Anweisungen oder sogar Funktionen verwenden, die das Ergebnis einer Select-Anweisung innerhalb des "SELECT"-Teils einer Abfrage zurückgeben.

Ich bin eigentlich überrascht, dass ich das nirgendwo anders hier sehe, vielleicht habe ich es übersehen, obwohl @adam ein ähnliches Problem angedeutet hat.

Beispiel:

SELECT
    (SELECT TOP 1 SomeValue FROM SomeTable WHERE SomeDate = c.Date ORDER BY SomeValue desc) As FirstVal
    ,(SELECT OtherValue FROM SomeOtherTable WHERE SomeOtherCriteria = c.Criteria) As SecondVal
FROM
    MyTable c

Wenn MyTable in diesem Szenario 10000 Zeilen zurückgibt, ist das Ergebnis so, als ob die Abfrage gerade 20001 Abfragen ausgeführt hätte, da sie die ursprüngliche Abfrage plus die Abfrage jeder der anderen Tabellen einmal für jede Zeile des Ergebnisses ausführen musste.

In einer Entwicklungsumgebung, in der nur wenige Datenzeilen zurückgegeben werden und die Untertabellen in der Regel nur eine geringe Datenmenge enthalten, können Entwickler damit auskommen, aber in einer Produktionsumgebung kann diese Art von Abfrage exponentiell teuer werden, wenn den Tabellen mehr Daten hinzugefügt werden.

Ein besseres (nicht unbedingt perfektes) Beispiel wäre etwas wie:

SELECT
     s.SomeValue As FirstVal
    ,o.OtherValue As SecondVal
FROM
    MyTable c
    LEFT JOIN (
        SELECT SomeDate, MAX(SomeValue) as SomeValue
        FROM SomeTable 
        GROUP BY SomeDate
     ) s ON c.Date = s.SomeDate
    LEFT JOIN SomeOtherTable o ON c.Criteria = o.SomeOtherCriteria

Dadurch können Datenbankoptimierer die Daten zusammenmischen, anstatt jeden Datensatz aus der Haupttabelle erneut abzufragen. Wenn ich Code korrigieren muss, bei dem dieses Problem aufgetreten ist, kann ich in der Regel die Abfragegeschwindigkeit um 100 % oder mehr erhöhen und gleichzeitig die CPU- und Speichernutzung verringern.