[linux-l] Vorbehalte gegen MySQL (was: MySQL PostgreSqL Drupal)

[Steffen Dettmer]

* Volker Grabsch wrote on Fri, Dec 28, 2007 at 01:57 +0100:
> Inzwischen hat MySQL endlich auch Transaktions-Unterstützung. Solange
> es das nicht hatte, war es keine /richtige/ Datenbank. Ein SQL-Interpreter
> mit Mehrbenutzerzugriff verdient noch nicht den Titel "Datenbank".

Ich hab mal gehört, dass man für Transaktions-Unterstützung bestimmte
Tabellenarten verwenden muss (den Namen hab ich vergessen), die auch
ziemlich langsam sind, bei den Performance-Vergleichtests aber die
anderen (schnellen) Tabellenarten verwendet werden, die aber eher ein
einfaches Dateisystem sind. Wobei ich mich frage, warum man nie
berkleyDB (diese .db Hashes von Sendmail und deren
`Nachfolgetechnologien') mit vergleicht. Ich denke, die sind noch
schneller als mySQL.

>    (Mit dem neuen RubyOnRails-Hype wird dieser Kreislauf zunehmens
>     durchbrochen: Ein neuer Markt bedroht die PHP-MySQL-Monokultur.
>     DB-Abstraktion wird modern.)

Ist ein Konzept von Rails nicht, die Datenstrukturen 1:1 zu übernehmen,
Objekte zu erzeugen, die `vom logischen Typ her' wie eine Tabelle sind
usw.? so ein programming-by-convention-Ansatz? Find ich nicht schön,
denn in solchen Fällen braucht man vielleicht überhaupt keine Datenbank.
Ich finde, dass abstrahiert nicht von einer Datenbank (also
Zugriffsoperationen und Regeln) sondern vom DBMS, also der Software, die
die Datenbank hat. Das mit DRY zu argumentieren, ist meiner Meinung nach
falsch. Es gibt Sichten auf Daten, dabei kann eine Applikation andere
haben, als die physikalische Datenbankstruktur. Bei richtigen
Datenbanken hat man ja dann sowieso mindestens zusätzliche Informationen
(und wenn es ein last_modified ist), die die Applikation nicht zu
interessieren haben. Ich finde, die Applikationen sollten die Daten
präsentieren, wie ein Mensch sie verarbeiten (und erfassen) möchte,
speichern sollte man sie hingegen, wie es richtig oder `natürlich' ist,
was oft gleich oder sehr ähnlich ist. Ob mein Datenbankview nun eine
cache-Tabelle benutzt oder nicht, darf die Applikation nicht wissen.

Ich glaube, Objekte und Tabellen als `redundant' zu bezeichen (weil ja
schliesslich beide einen Namen haben), ist falsch. Ein View nennt den
Namen, aber die Information ist nicht redundant, weil es eine Auswahl
ist (Name ist Element). Wenn die Leute genervt sind, weil sie ständig
Tabellen UND Applikation anpassen müssen, machen sie vielleicht was
falsch. Wenn ein last_modified Feld von der Applikation und nicht von
der Datenbank gesetzt werden muss, hat man meiner Meinung nach ein
schönes Beispiel für falsch. Meiner Meinung nach kann man jetzt auch
nicht unbedingt argumentieren, dass das ja langsam wäre. Aber wenn man
es schnell braucht, dann soll die Applikation bitte selbst die Tabellen
schreiben (.db files oder sowas), das ist schneller als noch ne TCP
connection mit serialisierten Daten füttern zu müssen. Überhaupt habe
ich den Eindruck, dass gerade mySQL gerade aus Faulheit verwendet wird
und nicht, weil man es braucht. Aber da hat man ein Tutorial für und ein
Beispiel hier und muss sich keinen Kopf machen (dementsprechend ist
natürlich das Ergebnis). Am Ende hat man dann ein Gästebuch für 10
Eintragungen, dass von 100 libraries (PHP) und einer Riesenapplikation
(mySQL) abhängt, was man auch mit paar hundert Zeilen Perl hinbekommen
hätte (oder python oder bestimmt auch Ruby).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.