AW: Grenzen von MySQL

[Guido Backhaus]

>>>>From: Andreas Müller <mysql at universalware.de>
>>>>Reply-To: mysql-de at lists.4t2.com
>>>>To: <mysql-de at lists.4t2.com>
>>>>Subject: AW: Grenzen von MySQL
>>>>Date: Thu, 6 Mar 2003 14:46:52 +0100
>>>>
>>>>Hallo,
>>>>
>>>> > Leider schneidet MySQL im Vergleich der Vorteile eben schlechter
>>>> > ab. Fertig und aus. Wenn's Dir nicht gefällt, dann kann ich es
>>>> > nicht ändern.
>>>>
>>>>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.
>>>>
>Gruß,
>Andreas Müller
>
DANKE!!!!!!!!!*g
MfG , Guido

_________________________________________________________________
Messenger  -  Wer in Echtzeit kommunizieren will, lädt den MSN Messenger. 
Cool, kostenlos und mit 3D Emoticons:  http://messenger.msn.de

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