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

[Volker Grabsch]

On Sat, Dec 29, 2007 at 06:06:13PM +0100, Steffen Dettmer wrote:
> * 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),

Ja, das hatte ich weiter unten auch beschrieben. Genauer gesagt wird
Transaktionssicherheit bei den Tabellentypen "InnoDB" und "BDB"
gewährleistet.

> 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.

> >    (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.

Das stimmt auch wieder. Das ist aber kein Rails-Problem, sondern eine
generelle Kritik an ORMs; eine IMHO berechtigte.

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.

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.

> 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).

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. Hat den Vorteil, dass man keinen Code zur
Serialisierung/Deserialisierung schreiben braucht, und dass
konkurrierender Zugriff (bin mir nicht sicher) geregelt wird.(?)

SQLite zusammen mit einem ORM erscheint dann als Overkill, weil man ja
auch "direkte" Objekt-Serialisierung nach JSON oder XML machen könnte.
Aber andererseits kann so die Applikation sowohl einen DB-Server als
auch Dateien benutzen, d.h. bei solchen Applikationen spart man es sich,
eine Objektserialisierung einzuführen, wenn doch schon SQL-Code hat.

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.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR