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

[Steffen Dettmer]

* Volker Grabsch wrote on Sat, Dec 29, 2007 at 23:21 +0100:
> > die auch ziemlich langsam sind, bei den Performance-Vergleichtests
> > aber die anderen (schnellen) Tabellenarten verwendet werden, die
> > aber eher ein einfaches Dateisystem sind.
> 
> Ja, genau das habe ich auch gehört. Das (und andere Dinge) meinte ich
> mit "unseröse Benchmarks". Details habe ich leider keine, daher habe
> ich bewusst nur von "Eindrücken" geschrieben.

Ja ja, schon klar. Fragt sich, wie seriös `seriöse Benchmarks' sind,
oder ob das auch eher Eindrücke sind... Bei PostgreSQL sind
Performanceunterschiede zwischen 1 und 1000 oder weiss ich was durchaus
möglich, je nach dem, wie geschickt oder ungeschickt man was ablegt,
definiert oder sowas. Na ja, ein weites Feld.

> Das ist aber eine andere Sache. Auch ohne Frameworks ist es in Python
> und Ruby seit je her üblich, das Programm *nicht* auf eine bestimmte
> DB festzulegen, außer vllt. durch ein paar kleine Unterschiede im
> verwendeten SQL-Dialekt. Und darum ging es mir.

Ja, also nicht so DB unabhängig, sondern DBMS unabhängig wollte ich
ausdrücken. Also das gleiche wie Du, nur ist `DB' für mich eine Instanz
von etwas, das in einem DBMS lebt (wenn man auf so einer genauen Ebene
ist). Umgangssprachlich erschliesst's sich natürlich meist aus dem
Kontext und man sagt schlicht `DB' und meint irgendwas.

> Da einen nun Webapplikationen nicht mehr unnötig auf eine bestimmte DB
> (z.B. MySQL) festnageln, verschwindet auch langsam der Reflex, für
> alles MySQL nehmen zu wollen.

SQL abstrahiert ja eigentlich schon; wenn jetzt mySQL kein richtiges SQL
kann... naja ;) Aber klar, SQL ist immer bisschen spezifisch, aber wenn
man das in der Applikation gut zentralisiert (so'n typisches access
layer hat), ist es in der Praxis wohl auch nur selten ein Problem,
mehrere zu unterstützen. Sowas in der Art verwenden wir z.b., da werden
ausschliesslich Stored Procedures verwendet. Die implementiert sich die
Datenbank je nach dem wie sie will und kann damit ggf. sämtliche DBMS
Funktionalität nutzen (und vor allem abstrahiert komplett von der DB
Struktur - im Extremfall braucht man nichtmal Tabellen :)). Da gibt's
dann verschiedene Zugriffstreiber, die man per Konfiguration auswählt.
Falls mySQL inzwischen Stored Procedures kann, sollte sich so ein
Treiber schnell schreiben lassen, falls denn wirklich kein bestehender
gehen sollte. Damit kann man oft leben, finde ich.

Worauf ich (und du ja auch :)) hinauswollte, waren so die Teile, wo in
PHP mit weit verteilten inline-mySQL-Queries irgendwas schon
prinzipbedingt nicht-atomares (weil Broserrequestübergreifendes) gemacht
wird usw.

Das ist natürlich weniger ein Thema für mySQL sondern mehr für schlechte
Software im allgemeine. Vielleicht gibt's da auch nur ne Häufung, dass
beides gleichzeitig zutrifft ^_^ 

> Interessant ist in dem Zusammenhang auch SQLite:
> 
>     http://www.sqlite.org/different.html
> 
> Das kann einfaches SQL, aber hat keinen DB-Server und speichert die
> Tabellen in flat-files. 

Ja, sowas ist schön, da verbaut man sich nicht, später SQL DBMSes nehmen
zu können. Es gibt auch ODBC-Treiber, die auf Dateien arbeiten.
Letztendlich ist auch Microsoft Access (so fast) ein Beispiel dafür,
glaube ich.

> SQLite zusammen mit einem ORM erscheint dann als Overkill, weil man ja
> auch "direkte" Objekt-Serialisierung nach JSON oder XML machen könnte.

Wenn man was nach XML serialisiert, wird dessen Verarbeitung aber
schnell teuer. Ich glaube, manch einer ist überrascht, wieviel Power XML
Verarbeitung kostet und wieviel schneller ein pragmatischer Ansatz sein
kann. Weiterhin hat sowas wie SQLite ja weitere Vorteile, beispielsweise
dank freien Speicherformates Indicies und so verwenden zu dürfen oder
padding einzufügen. Bei XML wird das schnell lahm, weil man u.U. grosse
Files komplett neu schreiben muss.

> SQLite ohne ORM ist jedoch interessanter, weil SQLite auch VIEWs
> unterstützt. So kann man SQL auch wirklich als /Sprache/ benutzen,
> und damit eine ganze (Abstraktions-)Schicht seiner Applikation
> realisieren.

Ja, schon interessant. Ich wollte man so ein Filebasierten ODBC Treiber
verwenden, aber das scheiterte vor dem Versuch, weil man (bei dem Teil
jedenfalls) keine Trigger oder Regeln verwenden konnte. Wenn ich aber
keine Trigger, Regeln und Rechte brauche, brauche ich ja vielleicht auch
keine Datenbank. Ein Webfrontend mit Schreibrechten auf alles (oder
überhaupt mit Schreibrechten direkt auf Tabellen) finde ich nicht so
schön (was anderes ist, wenn man (wie Du oben schriebst) es als
Hilfsmittel verwendet. Sozusagen als 4GL Sprache, um bestimmte Sachen
schöner und verständlicher ausdrücken zu können, um Fehler zu
vermeiden).

oki,

Steffen

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