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

• Keine Sicherung vor der Behebung eines Problems in der Produktionsdatenbank.

• Verwendung von DDL-Befehlen für gespeicherte Objekte (wie Tabellen, Ansichten) in gespeicherten Prozeduren.

• Angst vor der Verwendung von Stored Proc oder Angst vor der Verwendung von ORM-Abfragen, wenn diese effizienter/angemessener sind.

• Ignorieren Sie die Verwendung eines Datenbank-Profilers, der Ihnen genau sagen kann, in was Ihre ORM-Abfrage letztendlich umgewandelt wird, und somit die Logik überprüfen oder sogar für die Fehlersuche verwenden kann, wenn Sie ORM nicht verwenden.

Answer 2

Behandlung der Datenbank als reinen Speichermechanismus (d.h. glorifizierte Sammlungsbibliothek) und damit Unterordnung unter die eigene Anwendung (ohne Berücksichtigung anderer Anwendungen, die die Daten gemeinsam nutzen)

Answer 3

1 - Unnötige Verwendung einer Funktion auf einen Wert in einer Where-Klausel mit dem Ergebnis, dass dieser Index nicht verwendet wird.

Beispiel:

where to_char(someDate,'YYYYMMDD') between :fromDate and :toDate

anstelle von

where someDate >= to_date(:fromDate,'YYYYMMDD') and someDate < to_date(:toDate,'YYYYMMDD')+1

Und in geringerem Ausmaß: Nicht Hinzufügen von funktionalen Indizes zu den Werten, die sie benötigen...

2 - Keine Hinzufügung von Prüfbeschränkungen, um die Gültigkeit der Daten zu gewährleisten. Constraints können vom Abfrageoptimierer verwendet werden, und sie helfen WIRKLICH dabei, sicherzustellen, dass Sie Ihren Invarianten vertrauen können. Es gibt einfach keinen Grund, sie nicht zu verwenden.

3 - Hinzufügen von nicht normalisierten Spalten zu Tabellen aus reiner Faulheit oder unter Zeitdruck. Normalerweise sind die Dinge nicht so geplant, sondern entwickeln sich zu diesem Zustand. Das Endergebnis ist auf jeden Fall eine Menge Arbeit, wenn man versucht, das Chaos zu bereinigen, wenn man in zukünftigen Entwicklungen von der verlorenen Datenintegrität betroffen ist.

Stellen Sie sich vor, eine Tabelle ohne Daten ist sehr billig in der Umgestaltung. Eine Tabelle mit ein paar Millionen Datensätzen ohne Integrität ist nicht so billig umzugestalten. Der richtige Entwurf bei der Erstellung der Spalte oder Tabelle amortisiert sich also in hohem Maße.

4 - nicht so sehr über die Datenbank an sich, aber in der Tat ärgerlich. Keine Rücksicht auf die Codequalität von SQL. Die Tatsache, dass Ihr SQL in Text ausgedrückt ist, bedeutet nicht, dass es in Ordnung ist, die Logik in einem Haufen von Algorithmen zur Stringmanipulation zu verstecken. Es ist durchaus möglich, SQL in Textform so zu schreiben, dass es für andere Programmierer lesbar ist.

Answer 4

• Ein ORM wie Hibernate aus Gründen wie "es ist zu magisch" oder "nicht auf dem neuesten Stand" zu verwerfen meine Datenbank".
• Sich zu sehr auf ein ORM wie Hibernate zu verlassen und zu versuchen, es dort einzubauen, wo es nicht angebracht ist.

Answer 5

Nicht das richtige Maß an Normalisierung . Sie müssen sicherstellen, dass die Daten nicht doppelt vorhanden sind und dass Sie die Daten je nach Bedarf in verschiedene Bereiche aufteilen. Sie müssen auch sicherstellen, dass Sie die Normalisierung nicht befolgen zu soweit das die Leistung beeinträchtigen wird.