> > > > Die angesprochenen Performanceverbesserungen sind mir > > > wohlbekannt. Aber > > > > Welche Verbesserungen? Ich sprach von Verschlechterungen. > > > > Du hast einige Verbesserungsm�glichkeiten angesprochen wie > zwischenspeichern > von Werten in Applikation Variablen oder Textfiles.
Aja... Aber ich sehe kein Problem, wieso z.B. Userdaten o.�. nicht im Speicher gehalten werden k�nnen und bei neuen eintr�gen geupdatet werden... > > > Jeder Provider, der seinen Job ernst nimmt wird wenn M�glich > > connection-Pooling einstellen, denn es bringt auch ihm Vorteile... > > Weniger starke Auslastung der Server bedeutet, dass er mehr > Sites pro > > Server hosten kann... > > > > F�r SQL Server stimme ich dir generell mal zu, aber vorsicht > bei Access. > Wenn du das Connection Pooling f�r Access aktivierst hast du > ein Problem, > das wir bislang noch garnicht angesprochen haben, es wird je > nachdem extrem > Schwierig die Connections zu Wartungszwecken zu trennen (zB. DB > Komprimierung). �ber solche Anspr�che kann sich ein Provider > doch nicht > einfach hinwegsetzen. Das Problem hat man so oder so... W�hrend einer Komprimierung oder kopieren(download per ftp o.�.) muss man den Zugriff auf die DB verhindern... Ich nehme mal an, das ADO(X) sich drum k�mmert, das der Pool nicht andere Aktionen unterbindet... > > > �brigens gelten Deine Argumente auch gegen Dich... > > Du nutzt ODBC, aber bei den meisten Providern kostet das > > Einrichten von > > ODBC DSNs Geld... > > Es wird doch eine DSN lose Connection Benutzt? Dann habe ich Dich vielleicht verwechselt... Ich dachte Du willst unbeding ODBC nutzen.. > > > Ja, aber was ist den �berhaupt der Vorteil, den mann sich mit > > Performance-Verlust durch Dein System erkauft? > > > > Einfache Konfiguration, Downloads von meiner Seite laufen in einer > gemeinsamen Umgebung was eine Interaktion erlaubt, ohne zu > bedingen, das > alles installiert ist. Einfacheres verst�ndniss der Vorg�nge > im Quellcode, > weil nicht alles mit Standartvorg�ngen zugekleistert ist. Cookiefreies > Sessionhandling, hohe felxibilit�t bei einfacher installation. Das h�rt sich ja gar nicht so schlecht an... Aber das eigene Pooling sehe ich trotzdem nicht ein... Du handelst Dir wahrscheinlich mehr Probleme ein, als das Du l�st... F�r geringes Anfragenaufkommen ist Pooling nicht n�tig, weil es auch so schnell genug ist... Bei h�herem Anfragenaufkommen, wenn Pooling eigentlich interessant w�rde, bremst das Threading jeden Performance-Gewinn aus und verlangsamt noch zus�tzlich... Also: eigenes Pooling ist auf jeden Fall kontraproduktiv und ist ja auch nicht n�tig, nur um DB-Anfragen zu vereinfachen... > Ich f�rchte, du hast eine wichtigen Punkt missverstanden: Ich > will hier > keine Umgebung schaffen die nachher jeder nutzen soll, weil > das dann meinem > Ego gefallen w�rde. V�lliger Schmarrn. Aber Ich hab diesen N�, so hab ichs nicht verstanden... Wollte bloss die Nachteile dieses Vorgehens aufzeigen > Chat geschrieben > und ich habe noch ein Glossar zum Download auf der Page. Beiden fehlt > beispielsweise eine Benutzerverwaltung. Als n�chstes bastle > ich an einem > Forum, da der Chat sicher viele Fragen aufwerfen wird. Das > werde ich dann > nat�rlich auch im Quellcode ver�ffnetlichen. Auch hier ist wieder eine > Verwaltung gefragt. > Also war meine �berlegung, erst einmal eine Basis zu > schaffen, die all diese > Applikationen gemeinsam nutzen k�nnen und die so leicht wie m�glich > konfigurierbar und nutzbar ist, auch f�r jene, die nicht wissen. > > Gru�, Andreas. > PS: Wir haben hier 2 St�hle, eine Meinung. Wir stehen hier nicht > Grunds�tzlich gegeneinander Sowieso nicht... Claudius | [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
