Grenzen von MySQL

[Michael Post]

Hallo Andreas,

>         From: Andreas Müller [mailto:mysql at universalware.de]
>         Sent: Thursday, March 06, 2003 2:47 PM
>         To: mysql-de at lists.4t2.com
>         Subject: AW: Grenzen von MySQL
>
>
>         Also der Vergleich von Vorteilen ist nicht gerade sehr
>         aussagekräftig.
>         Außerdem ist es sehr schwer die bessere Datenbank zu bestimmen.
>
>         Ich kann hier mal versuchen meine Meinung wiederzugeben:
>         Ich habe selbst bei
>         uns recht viele Datenbanken getestet und auf ihre
>         Praxistauglichkeit für
>         unsere Anwendungsfälle untersucht. Diese reichen von
>         Anwendungen im ERP
>         Bereich in Monolitischer- bis Multi-Tier-Architektur
>         bishin zu kleinen oder
>         größeren Webprojekten.
>         Ich kann mal ein paar Gedanken und Eindrücke zu
>         verschiedenen Datenbanken
>         geben (Syteme getestet auf Win32/Linux):
>
>         Interbase:
>         Klein, recht einfach im Handling, ausreichend mächtige
>         SQL Implementierung,
>         mittlerer Wartungsbedarf, sehr schlechter Optimizer,
>         geringes Ausfallrisiko,
>         hohes Datenverlustrisiko bei leicht beschädigter
>         Datenbank, hohe relativ
>         hohe Server Belastung im Dauerbetrieb
>
>         Oracle:
>         Sehr fettes System, recht kompliziert im Handling, sehr
>         langsame und
>         aufwändige Adminstration, sehr mächtige aber eigenwillige SQL
>         Implementierung, hoher Wartungsbedarf, sehr guter Optimizer, hohes
>         Ausfallrisiko in Black Box Anwendungen da ständige
>         manuelle Überwachung
>         nötig, mittleres Datenverlustrisiko bei leicht
>         beschädigter Datenbank,
>         mittlere Server Belastung im Dauerbetrieb, merkwürdiges
>         Index-Aktualisierungsverhalten bei großen Tabellen
>         teilweise mehreren
>         Stunden Rebuild Zeit, Administrator mit sehr guten
>         Kenntnissen benötigt
>
>         DB2:
>         Sehr fettes System, recht komplizierte im Handling, sehr
>         langsame und
>         aufwändige Adminstration, sehr mächtige aber eigenwillige SQL
>         Implementierung, hoher Wartungsbedarf, schlechter
>         Optimizer, hohes bis sehr
>         hohes Ausfallrisiko in Black Box Anwendungen da ständige manuelle
>         Überwachung nötig, mitteres bis sehr hohes
>         Datenverlustrisiko bei leicht
>         beschädigter Datenbank oder vollem Logfile, sehr hohe
>         Server Belastung im
>         Dauerbetrieb, sehr hohe Latenzzeit bei Commandoausführung
>         (weilweise 3-5
>         Sekunden)
>
>         MS-SQL:
>         Mittelfettes System, recht einfach im Handling, mitteprächtige
>         Administration, sehr mächtige aber eigenwillige SQL
>         Implementierung,
>         mittlerer Wartungsaufwand, schlechter Optimizer, geringes
>         Ausfallrisiko,
>         hohes Datenverlustrisiko bei leicht beschäigter
>         Datenbank, mittlere
>         Serverbelastung im Dauerbetrieb, mitunter merkwürdiges
>         Verhaltung bei
>         Sperren von Objekten
>
>         MySQL:
>         Sehr kleines System, recht einfach im Handling,
>         verhältnismäßig aufwendige
>         Administration magels Tools ansonsten sehr reinfach,
>         nicht ausgereifte SQL
>         Implementierung mit eigenwilligen Ergänzungen, geringer
>         Wartungsaufwand,
>         sehr guter Optimizer, sehr geringes Ausfallrisiko,
>         relativ geringes (MyISAM)
>         bis mittleres (InnoDB) Datenverlustrisiko bei leicht
>         beschädigter Datenbank,
>         geringe Serverbelastung im Dauerbetrieb
>
>
>         Was mit an MySQL Fehlt ist die saubere SQL
>         Implementierung. Wenn es diese
>         einmal geben sollte dann sehe ich kaum Gründe außer in
>         extrem großen System
>         auf eine andere Datenbank zu gehen. Ich habe mit allen
>         anderen Datenbanken
>         bisher schon heftige Datenverluste erlitten, mit MySQL
>         noch nicht einen
>         einzigen. Außerdem lohnt ein Blick auf die Lizenzpolitik der
>         Datenbankhersteller.
>
>         Noch was tum Thema Stored Procedures und Views: Wenn man mal große
>         Anwendungen baut und sich nicht 100% auf einen Server
>         festlegen will und
>         seine Anwendung auch pflegbar lassen will dann wird man
>         sich sehr schnell
>         von diesen "Features" verabschieden. Denn sie bringen
>         rein garnichts.
>         StoredProcedures sind nicht portabel und Views behindern
>         Strukturänderungen
>         teilweise erheblich. Auch referrenzielle Integrität via
>         Foreign Key Angaben
>         in Tabellen sind meiner Meinung nach tödlich für
>         Strukturänderungen. Das
>         gehört für mich alles in den Abstraktionslayer der
>         Anwendung, die weiss viel
>         besser was sie tut. Gerade bei Foreign Keys ist es oft
>         das Problem Daten zu
>         importieren in einer angemessenen Zeit. Werd schonmal
>         Systeme migiriert hat
>         kann ein Lied davon singen. Und das alles nur weil man den
>         Anwenungsentwicklern untersagen will was sie machen. Für
>         mich die falsche
>         Stelle in der Datenbank.


den obigen Bericht fand ich sehr gut. Zumindest um mal grob einen guten
Überblick zu bekommen.
Wie würdest Du denn PostGreSql darin beschreiben?


Gruß Michael

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql