Oft schau ich mir Code an und sehe, dass Leute offenbar zu faul f\u00fcr vern\u00fcnftige 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?<\/b> Die Datenbank ist doch zum rechnen und f\u00fcr 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\u00fcrden?<\/p>\n
\r\nSELECT price FROM product\r\n<\/pre>\n\r\nwhile ($row = $sql->fetch())\r\n{\r\n print $row['price'] * 1.95583;\r\n}\r\n<\/pre>\nWarum nicht einfach:<\/p>\n
\r\nSELECT price*1.95583 AS europreis FROM product\r\n<\/pre>\nOkay, jetzt nicht das beste Beispiel aber prinzipiell l\u00e4uft einem sowas \u00f6fter \u00fcber den Weg.<\/p>\n
Datenbank-Konsistenz<\/h2>\n
Ich kann auch nicht verstehen, warum die Leute alle die absolut geilen InnoDB-Features au\u00dfen 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\u00e4hltes Fremdschl\u00fcssel-Datenmodell erledigt sowas doch, daf\u00fcr ist es gemacht!<\/p>\n
Transactions<\/h2>\n
Auch sehr gern gesehen: Menschen programmieren selbst eine Rollback-Funktionalit\u00e4t, um fehlgeschlagene Abfragen revidieren zu k\u00f6nnen. Da werden dann Arrays mit wiederherzustellenden Werten angelegt, falls eine Abfrage nicht klappt. Daf\u00fcr gibt es doch Transaktionen! Die k\u00f6nnen genau das und zwar wesentlich besser. Au\u00dferdem kann man Transaktionen garnicht vollst\u00e4ndig emulieren<\/a>.<\/p>\nValidierung<\/h2>\n
Viel zu selten benutzt: Enum und Set<\/a>. Warum nicht die M\u00f6glichkeit nutzen, nur bereits vordefinierte Werte zuzulassen? Das ist immerhin die wasserdichteste Variante, um sicherzustellen, dass nur zugelassene Werte in der Datenbank landen.<\/p>\nWertepr\u00fcfung<\/h2>\n
Im Artikel MySQL Inputvalidierung mit Triggern<\/a> stelle ich einen Weg vor, wie man mittels Triggern erreichen kann, dass nur gewisse Wertebereiche in Tabellen eingef\u00fcgt werden d\u00fcrfen. Daran scheiden sich allerdings die Geister, ob man das zur „best practice“ ernennen sollte, weil Trigger „versteckt“ auf der Datenbank agieren und f\u00fcr ordentlich Verwirrung sorgen k\u00f6nnen.<\/p>\nDatumsberechnungen<\/h2>\n
Oft brechen sich Programmierer auch die Wurst mit strtotime, date und mktime<\/i> ab, um Daten zu updaten. MySQL bringt aber hier – genau wie alle anderen ernstzunehmenden DBMS auch – wunderbare Zeitfunktionen<\/a> 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.<\/p>\n","protected":false},"excerpt":{"rendered":"Oft schau ich mir Code an und sehe, dass Leute offenbar zu faul f\u00fcr vern\u00fcnftige 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? … Weiterlesen