Hallo Joachim, ich will die Leistungsf�higkeit und Performance des SQL Servers in keiner Weise in Frage stellen, auch denke ich - und das wird jeder Anwender einer relationalen Datenbank so sehen - ist jede DB Anwendung nur so gut wie sie designt ist, aber es ging ja im Thread um das f�r und wider zwischen MySQL und SQL Server.
Ich pers�nlich nutze vorrangig MySQL und ich kann auch nur daf�r die Lanze brechen. Im �brigen lese ich aus Deinem Posting so ein wenig eine Verteidigungs Argumentation. Das ist �berhaupt nicht n�tig, da wir alle wissen wie gut SQL Server ist. Zum Punkt der Recordset Performance. Ich habe - wie ich denke - ein sehr anspruchsvolles Board geschrieben, dass die Threads komplett aus einem einzigen Recordset ausliest und dabei genau diese angesprochene Hierarchie ausf�hren mu�. Bei einem Thread mit 460 DS, teilweise mit ordentlich gef�llten Textfeldern (ca. 600 bis 3000 Zeichen) und mindestens zwei Joins, liegt die durchschnittliche Zugriffsgeschwindigkeit bei 1,8 Sekunden. Dabei werden s�mtliche Re Beitr�ge exakt in die Hierachie gestellt, die zum einen nach der Reihenfolge der Eintragung und zum anderen, passend nach Thread und Datum eingetragen werden. Sicherlich sind 1700 DS noch keine Menge, aber kritisch wird das erst ab 50000 DS. Erst ab dieser Zahl mu� man wohl mit einer Verz�gerung von ein bis zwei Sekunden rechnen. Wenn die ASP Seite den HTML Code schneller laden k�nnte, ich auf Loops in Tabellen verzichtet h�tte, dann w�rde man nicht l�nger als eine Sekunde auf die ersten Ergebnisanzeigen warten. Im Vergleich zu Access sind das bereits Welten, im Vergleich zu SQL Server kann ich keine Aussage machen, aber MySQL kann mehr als mancher denkt. Also wie gesagt, von mir aus sollen alle SQL Server nutzen aber man sollte sich vorher auf jeden Fall mal MySQL n�her anschauen. Zumal hier noch der Kostenvorzug zum tragen kommt. GPL ist zwar auch nicht jedermanns Sache, aber ich habe bisher noch nicht geh�rt, dass Monty einen vor den Kadi gezogen hat ! J�rg Schwalenberg _______________________________ Extensions and Basics for Macromedia "Dreamweaver Ultradev" .............................................................. www.ultradevextensions.de www.udex.de [EMAIL PROTECTED] _______________________________ ----- Original Message ----- From: "Joachim van de Bruck" <[EMAIL PROTECTED]> To: "ASP Datenbankprogrammierung" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 9:09 PM Subject: [aspdedatabase] AW: Re: AW: Re: AW: Re: AW: MySql und ASP? Hallo! > Ja genau hier ist der Ansatz zum nachdenken. > > SQL Server verursacht Kosten beim Provider und es ist mir auch kein Fall > bekannt, wo ein Versuch die Clients zu umgehen funktioniert h�tte. > > Jetzt kommen wir wieder zu MySQL zur�ck. Wer auf Stored Proz., Abfragen und > Trigger verzichten kann, der ist mit MySQL optimal versorgt. Wem diese > Funktionen - ca. 600,00 DM/Jahr - unentbehrlich sind, der ist nat�rlich mit > SQL Server optimal versorgt. > > Die Performance von MySQL, mit einer guten Indexierung, ist sogar dem SQL > Server �berlegen. Das wird leider immer wieder behauptet, ist aber ganz bestimmt nur in Ausnahmef�llen richtig. Richtig ist lediglich, dass Daten�nderungen schneller laufen, weil ja auch keine Transaktionen, Fremdschl�sselbeziehungen, referentielle Identit�ten, verteilte Datenbankstrukturen, oder Trigger- und Check-Funktionen ber�cksichtigt werden m�ssen. Daten�nderungen sind aber in der Regel zeitunkritisch, weil sie im Batch laufen oder aber schon durch die Eingabe �ber die Tastatur gebremst werden. Zeitkritisch ist in den wenigsten F�llen das "SELECT", sondern viel h�ufiger die �bertragung der Datenmenge vom Datenbankserver zum aufrufenden Programm. Und hier sind dann Stored Procedures/Functions, Sub-Selects und Trigger in der Lage, dem SQL Server jede Menge Zeitvorteile zu verschaffen. Man versuche nur einmal eine hierarchische Menustruktur aus mySQL in ein einziges richtig sortiertes Recordset zu lesen. Und wenn ich alles, was mySQL nicht kann, mit interpretiertem VBScript nachbilden muss, sieht mySQL ganz sch�n alt aus. > Die Frage ist hier, wie oft werden die ob. gen. Funktionen des SQL Servers > ben�tigt ? > Daraus ergibt sich die Antwort auf die Datenbank Auswahl. mySQL ist bestenfalls f�r ein einfaches Shop-System geeignet, je mehr Tabellen miteinander verkn�pft werden, desto besser wird der SQL Server. F�r eine komplexere Datenlogik ist der SQL Server (oder Oracle, db2, Informix, ...) sogar unentbehrlich. mySQL ist immer noch kaum mehr als ISAM. 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 | [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
