Mailinglisten-Archive |
könntest du das mal in einer lesbaren form posten ? -----Ursprüngliche Nachricht----- Von: Guido Backhaus [mailto:genusr_77 at hotmail.com] Gesendet: Montag, 10. März 2003 12:29 An: mysql-de at lists.4t2.com Betreff: Re: AW: Grenzen von MySQL >>>>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 -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive