Hallo! Die meisten Argumente habe ich aus der Dokumentation zu mySQL und nat�rlich wirst Du auch im Archiv dieser Liste f�ndig.
1. keine Transaktionen 2. keine Views 3. keine Stored Procedures und keine Trigger 4. keine Sub-Selects 5. keine Foreign-Key-Funktionen 6. keine Data Transformation Services 6. keine XML-Unterst�tzung 7. keine ADO-Unterst�tzung Daraus resultiert: 1. l�ngere Entwicklungszeiten 2. keine Kapselung der Datenlogik 3. Datenintegrit�t unsicher / aufwendig Daraus ergibt sich nur ein sehr kleines Anwendungsspektrum f�r mySQL: n�mlich als Desktop-Datenbank oder als Serverdatenbank, wenn nicht viele verkn�pfte Tabellen ben�tigt werden. Tats�chlich f�hrt das Fehlen von so elementaren Funktionen dazu, dass die restlichen Standards in mySQL sehr, sehr schnell sind. Das ist aber gerade im Hinblick auf Web-Programmierung tr�gerisch, weil man dann ja alles z. B. mit ASP/VBScript machen muss. Ein INSERT oder UPDATE muss also schneller als in Access oder SQL Server sein, da keine Transaktionen oder Trigger oder Fremdschl�ssel ber�cksichtigt werden. Aber in der Regel ist doch der Benutzer an der Tastatur die Bremse bei einem INSERT oder UPDATE, oder? Auch ein komplexes SELECT ist h�ufig selbst in Access schneller als in mySQL, n�mlich dann, wenn man alles in einer einzigen Datenbankabfrage erledigen kann, anstatt komplexe Verschachtelungen in VBScript zu erstellen. Um Missverst�ndnissen vorzubeugen: Nat�rlich kann man mit mySQL genau das machen, was man mit Access oder SQL-Server auch machen kann. Aber man muss viele Dinge selber schreiben, was die Entwicklungszeit erh�ht und dazu f�hrt, dass man den Code zur Datenlogik in allen Client-Applikationen pflegen muss. Und es gibt auch Anwendungen, die mit einer einfachen Datenbankstruktur und ohne Datenlogik auskommen. Diese k�nnen durchaus die Vorteile von mySQL in Verbindung mit C++ nutzen. VBScript ist allerdings so langsam, dass es eigentlich auf jede Hilfe von ADO oder der Datenbank selbst angewiesen ist. Eine einfache Applikation wie eine Adressverwaltung scheitert in mySQL, wenn das Szenario etwas komplexer wird: Unterstellen wir, dass die Daten �ber einen Import oder �ber das Internet oder �ber eine Client-Server-Applikation in die Address-Datenbank gelangen k�nnen, und schon muss man mehrere Aspekte der Datenlogik dreimal programmieren, n�mlich f�r jeden Client. Das ist an sich schon ein Unding und im Hinblick auf die Web-Applikation sehr unperformant. Mit Access oder gar SQL-Server habe ich hier deutlich weniger Arbeit, weil nahezu alles nur einmal in der Datenbank definiert werden muss. Ohne Transaktionen, Trigger und Stored Procedures kann auch keine Datenintegrit�t gew�hrleistet werden; Access hat hier immerhin noch rudiment�re Funktionen, mit denen man das Gr�bste erledigen kann. Aber das Fehlen solcher Funktionen ist bereits das Sicherheitsloch. Das Fehlen von Views und Transaktionen macht das Arbeiten sehr umst�ndlich. Im Schnitt habe ich zu jeder Tabelle in der Datenbank 5 Views und 2 Stored Procedures um bestimmte Aufgaben f�r unterschiedliche Anwendungen zu automatisieren. So m�ssen diese nur einmal entwickelt und getestet werden. Eine Datenbank ohne Views oder Abfragen ist wirklich sehr propriet�r und Transaktionen sind f�r viele Applikationen (wenn auch selten im Web) unabdingbar, so dass hier mySQL sofort ausscheidet. Im Web k�nnen Probleme mit unterschiedlichen Gebietsschemata f�r Datenbank, IIS sehr einfach mit Abfragen bzw. Views und Stored Procedures umgangen werden. Tats�chlich interessiert mich eigentlich nie, welches Datums- oder W�hrungsformat auf den Servern (Datenbank oder IIS) eingestellt ist. mySQL ist also gut, wenn man eine Mailingliste auf einem Apache-Server unterbringen muss. Sobald man mehrere Tabellen mit logischen Verkn�pfungen ben�tigt, ist mySQL gerade im Web sehr unperformant und nat�rlich sehr umst�ndlich zu testen und zu programmieren. Hier ist selbst Access deutlich schneller und einfacher. Die wenigen ernsthaften Bef�rworter von mySQL kennen und nutzen und ben�tigen sehr wahrscheinlich nicht die M�glichkeiten professioneller Datenbanksysteme und haben noch nie was davon geh�rt, welche Vorteile es bringt, die Datenlogik von der Business- und Pr�sentationslogik zu trennen. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
