Oft schau ich mir Code an und sehe, dass Leute offenbar zu faul für vernünftige SQL-Statements sind. Da wird eine extrem allgemein gehaltene Abfrage auf die Datenbank losgelassen, um dann im Nachklang mit PHP zu filtern / zu gruppieren. Warum? Die Datenbank ist doch zum rechnen und für genau so Aufgaben gedacht. Zudem ists auch noch viel performanter, die Datenbank einfach ihren Job erledigen zu lassen. Vielleicht programmieren gewisse Leute einfach viel zu gern PHP, als das sie sich von der Datenbank die Arbeit abnehmen lassen würden?
Berechnungen im SELECT
SELECT price FROM product
while ($row = $sql->fetch())
{
print $row['price'] * 1.95583;
}
Warum nicht einfach:
SELECT price*1.95583 AS europreis FROM product
Okay, jetzt nicht das beste Beispiel aber prinzipiell läuft einem sowas öfter über den Weg.
Datenbank-Konsistenz
Ich kann auch nicht verstehen, warum die Leute alle die absolut geilen InnoDB-Features außen vor lassen. Foreign Keys zum Beispiel. Da werden dann in Cronjobs abenteuerliche Abfragen auf die Datenbank abgesetzt, um die Konsistenz wieder herzustellen. Ein gut gewähltes Fremdschlüssel-Datenmodell erledigt sowas doch, dafür ist es gemacht!
Transactions
Auch sehr gern gesehen: Menschen programmieren selbst eine Rollback-Funktionalität, um fehlgeschlagene Abfragen revidieren zu können. Da werden dann Arrays mit wiederherzustellenden Werten angelegt, falls eine Abfrage nicht klappt. Dafür gibt es doch Transaktionen! Die können genau das und zwar wesentlich besser. Außerdem kann man Transaktionen garnicht vollständig emulieren.
Validierung
Viel zu selten benutzt: Enum und Set. Warum nicht die Möglichkeit nutzen, nur bereits vordefinierte Werte zuzulassen? Das ist immerhin die wasserdichteste Variante, um sicherzustellen, dass nur zugelassene Werte in der Datenbank landen.
Werteprüfung
Im Artikel MySQL Inputvalidierung mit Triggern stelle ich einen Weg vor, wie man mittels Triggern erreichen kann, dass nur gewisse Wertebereiche in Tabellen eingefügt werden dürfen. Daran scheiden sich allerdings die Geister, ob man das zur „best practice“ ernennen sollte, weil Trigger „versteckt“ auf der Datenbank agieren und für ordentlich Verwirrung sorgen können.
Datumsberechnungen
Oft brechen sich Programmierer auch die Wurst mit strtotime, date und mktime ab, um Daten zu updaten. MySQL bringt aber hier – genau wie alle anderen ernstzunehmenden DBMS auch – wunderbare Zeitfunktionen mit. Weiterer Vorteil dabei: Man ist nicht mehr darauf angewiesen, dass die Zeit des Datenbankservers und des Webservers sekundengenau gleich eingestellt ist, weil alle Zeitberechnungen nur noch auf Datenbankseite erledigt werden.
Mein Name ist
Die eine Möglichkeit ist Faulheit.
Aber ich denke es gibt auch einige Entwickler, die sich mit Datenbanken und ihren Möglichkeiten einfach zu wenig gut auskennen um sie auch zu nutzen.
Andersherum hat ein DB Spezialist die Tendenz alles auf die Datenbank auszulagern (z.B. Stored Procedures).
Ich glaub es liegt wie erwähnt einfach dadran, dass die Leute sowohl keine Ahnung von effizienter Datenbank-Programmierung haben, wie auch den Hang zum Coden in sich tragen und daher lieber selbst noch rumwurschteln.
Naja, es ist nicht nur „Unwissenheit“.
Enum & Datum => ok, deren Benutzung kann ich verstehen
ABER zum Rest:
IMHO wiederspricht es dem SRP (Single Responsibility Principle)
zB Validierung =>
Im Web 2.0 Zeitalter mit Live-Formularvalidierung prüft man schon während dem Ausfüllen, ob die Daten passen.
Da ist eine weitere DB-Seitige Validierung unnötig.
Dann zum Preischeck:
Mal angenommen, ich würde von einem Kunden so ein Projekt zum Weiterentwickeln bekommen.
Persönlich würde ich doch nie im Leben auf die Idee kommen, in der DB danach zu suchen, falls ich es ändern müsste.
Hm? Was hat denn eine Live-Validierung – bestenfalls noch pur clientseitig ;) – mit ineffizienten DB-Abfragen zu tun? Zu deinem zweiten Punkt hatte ich ja angesprochen, dass Trigger / CHECK-Klauseln (siehe anderer Post zu den Triggern) fiese Nebenwirkungen haben können, ja.
Stimme in allen Punkten voll zu. Allerdings sollte man der Datenbank auch nicht zuviele Aufgaben geben und sie nur zum Speichern und Abfragen der Daten verwenden. Dabei kann die SQL-Query ruhig sehr komplex sein und alle Berechnungen durchführen, das meine ich nicht mit den zuvielen Aufgaben. Ich meine eher Stored Procedures (wie sie Ralph angesprochen hat). Ich möchte in meinem PHP-Code sehen, was vor sich geht, und nicht erst noch die Datenbank unter die Lupe nehmen müssen, wenn etwas nicht funktioniert.
Zu den Datumsberechnungen: In bestimmten Fällen kommt es auf Performance an und dann ist es besser die PHP-Äquivalente benutzen.
Abfragen, die folgende Syntax beinhalten landen nicht dauerhaft im Query-Cache, sondern werden jedes Mal neu berechnet:
WHERE date = DATE_SUB(curdate(), INTERVAL 7 day)
Abfragen, die (mit PHP generiert) so aussehen schon:
WHERE date = 1297813003
Natürlich sind so Sachen wie Gruppieren und Sortieren mit einer Programmiersprache gar nicht gut, wenn das mit der Datenbank gemacht werden kann.