> > Hallo > > >Wie meinst Du das? Es gibt doch nur eine Session... > > JA, aber mehrere Variablen.
Schon klar... Aber eine sessionID = eine Session Siehe auch nochmal das DB-Schema... Ist das klar geworden wie ich es meine ? > > >DB k�nnte so aussehen: > > > >Sessions: > >sessionID PK > >lastAccess > >Timeout > > > >SessionData: > >Id PK > >Session FK > >Name > >value > > > > > Ist das zuviel? Sollte ich wirklich alles in einer DB speichern? > > > Ist es dann nicht viel langsamer, wenn ich jedesmal die Daten > > > aus der DB > > > rauslesen muss? > > > >Deshalb ja auch die Idee mit der Cache-Architektur... Dann musst Du > >nicht immer zur DB... > >Jedenfalls nicht f�rs lesen, sondern nur zum schreiben... > > > >Generell gesagt ist aber Performance eher ein Problem bei > Access-DBs als > >beim SQLServer... > > BINGO > > Ich hab eine Access-DB. Desshalb schreib ich auch viel in die > Sessions, > damit ich nicht jedesmal z.B. die W�hrung, die Lieferart,... > des Kunden in > Erfahrung bringen muss. > > Was ist jetzt genau der Vorteil von dieser Variante zur > Variante mit dem > speichern der UserID uns zugriff mit der UserID auf den Warenkorb? > Sorry, wenn ich so bl�de frage. > Dass musst Du nicht unbedingt implementieren, weil es eine gr�ssere �nderung ist... Die bisherigen �nderungen haben ja schon eineige Verbesserungen gebracht... Du solltest auch genau verstehen was Du tust, bevor Du es live einsetzt... Der Vorteil ist, dass Du lange Session-Timeout haben kannst, ohne dass Dir der Speicher mit Session-Daten volll�uft(iih.. Neue Rechtschreibung). Ausserdem Unabh�ngigkeit von Cookies... Claudius | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
