Online-Shop besucher verwalten

[christian]

guten morgen,

bin gerade dabei einen Online-shop mit einer mysql-db, in zusammenhang mit php auszutüfteln. Technisch dürfte das nicht eiter schwierig sein, aber ich weiß noch nicht ganz wie ich am besten die benutzer verwalte. Folgene Möglichkeiten:

ist es Besser eine einfach eine tabelle anzulegen die min. 3 spalten hat mit id, Login, passwort, diese dann immer auszulesen beim login und eine neue session beginnen(alle sind dann mit dem selben db-user mit der db verbunden), oder folgendes...

für jeden registrierten besucher, gibt es einen eigenen db-user. jedes mal wird dann ein neuer db-user angelegt, sobald sich jemand neu registriert. Wenn dieser dann sich wieder einlogt bekommt er eine verbindung zur db mit seinen eigenen db-user.

Also mir sagt möglichkeit 1 eingentlich mehr zu aber ich weiß nicht wies mit der Performence dann aussieht wenn mehrere gleichzeitig mit dem selben db-user verbunden sind. Jeder soll seinen eingenen Warenkorb bekommen usw...

würd mich über ein statement von euch freuen:-) was haltet ich für sinnvoller, oder besser gesagt was ist üblicher.

grüße aus hamburg

[Philipp Hasenfratz]

Halihallo

ist es Besser eine einfach eine tabelle anzulegen die min. 3 spalten hat mit id, Login, passwort, diese dann immer auszulesen beim login und eine neue session beginnen(alle sind dann mit dem selben db-user mit der db verbunden), oder folgendes...

Dies würde ich empfehlen.

für jeden registrierten besucher, gibt es einen eigenen db-user. jedes mal wird dann ein neuer db-user angelegt, sobald sich jemand neu registriert. Wenn dieser dann sich wieder einlogt bekommt er eine verbindung zur db mit seinen eigenen db-user.

Würde ich nicht empfehlen. Der administative Aufwand ist zu hoch. Zudem: Die DB - Daten gehören _nur_ dir! - Ein User-Account! - Alle Scripts sollen sich mit demselben Pwd/Login anmelden (ist dann auch einfacher, da du die Konfiguration in einem Config-file ablegen könntest). Und wenn die DB nicht gegen aussen (Internet) geschützt ist, ist die Attacken-Chance grösser (mehrere mögliche Logins).
Dein erster Vorschlag ist auch einfacher zu implementieren. Die Tabellen-relationen sind deutlich ersichtlich und vereinfachen das Programm/Verständnis.

Also mir sagt möglichkeit 1 eingentlich mehr zu aber ich weiß nicht wies mit der Performence dann aussieht wenn mehrere gleichzeitig mit dem selben db-user verbunden sind. Jeder soll seinen eingenen Warenkorb bekommen usw...

Die Performance ist nicht arg anders. Ob nun ein User, oder mehrere spielt gar keine Rolle. Es spielt lediglich eine Rolle wieviele Requests pro Zeiteinheit bei der DB ankommen.

würd mich über ein statement von euch freuen:-) was haltet ich für sinnvoller, oder besser gesagt was ist üblicher.

Meiner bescheidenen Meinung nach erstere...

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo again

zum DB-Schema:

wie willst du die Cart-Tabelle (Warenkorb) mit dem User verknüpfen, wenn dieser nicht auch in einer anderen Tabelle gespeichert ist? - Nur durch den Login? - Würde folgendes Vorschlagen:

Tabelle User:

UserID (autoincrement)
Login
Password

Tabelle Cart:

CartID (autoincrement)
UserID (Foreinkey zu Tabelle User)
Creation (Datetime)

Tabelle CartItem:

CartItemID (autoinc)
CartID
ProductID
Amount (Anzahl des Produktes)

Tabelle Product:

ProductID (autoinc)
Name
Description
Price
...

Vielleicht hilft dir das was

Philipp

[Andreas]

Hallo Philipp,

Tabelle Cart:

CartID (autoincrement)
UserID (Foreinkey zu Tabelle User)
Creation (Datetime)

Tabelle CartItem:

CartItemID (autoinc)
CartID
ProductID
Amount (Anzahl des Produktes)

könnte man nicht die Spalte CartItemID aus der Tabelle CartItem entfernen und dafür CartID und ProductID zum PrimaryKey machen? Dann könnte man sich diese Spalte sparen. Oder übersehe ich da etwas?

Viele Grüße, Andreas

[Philipp Hasenfratz]

Halihallo

könnte man nicht die Spalte CartItemID aus der Tabelle CartItem entfernen und dafür CartID und ProductID zum PrimaryKey machen? Dann könnte man sich diese Spalte sparen. Oder übersehe ich da etwas?

Wenn man nicht verschiedene "Bestellungen" des selben Produktes machen kann, dann ja.
Es mach vielleicht irgendwann Sinn folgendes zuzulassen:

CartItemID=5
CartID=2
ProductID=5
Amount=10
DeliverAddress=26

CartItemID=6
CartID=2
ProductID=5
Amount=15
DeliverAddress=27

vielleicht will der Kunde zweimal das selbe Produkt bestellen, aber verschiedene Empfänger-Adressen angeben (einmal für sich zu Hause und für's Geschäft). Dann geht's nicht ohne CartItemID. Aber dieser Fall (bzw. ähnliche Fälle) ist sehr, sehr unwahrscheinlich.
Dies nur als Beispiel.
Grundsätzlich hast du recht. Für die meisten Anwendungen geht dies ohne weiteres (zwei Columns als Primary Key).

Diese Frage muss man sich stellen, um zu entscheiden, ob CartItemID nötig ist, oder nur einen Primary über zwei Spalten:

Soll der Kunde zwei Bestellungen des selben Artikels in den Warenkorb legen können, oder soll beim erneuten bestellen des selben Artikels einfach der Amount erhöhen?

Viele Grüsse

Philipp

[Frank Jonas]

Hallo Christian,

ich habe im letzten Jahr 2 Projekte gemacht mit unterschiedlichen Randbedingungen.
Ein Projekt mit ASP, welches allerdings nur einem bestimmten Kreis an Leuten zugängig war. Dort haben wir es so gelöst, das wir eine Funktion haten, die wir verwendet haben, um auf die DB zuzugreifen, sprich mit einem User (ähnlich wie Ansatz 1). Im Code wurde die Verbindung geöffnet, das Statement ausgeführt und die verbindung wieder geschlossen. Wie gesagt mit relativ geringer Zugriffsmenge auf die Seiten.
Für einen Ticketshop mit wesentlich mehr Traffic haben wir uns einen kleine Application-Server gebaut, der 5 Connections aufbauen kann und die dann weiterreicht. Ich glaube allerdings, das ist ein Ansatz, den Du nicht verwendest.
Performance-Probleme hatten wir bei beiden bisher nicht. Du solltest halt schauen, wieviel Zugriffe Du einplanst. Wie das mit den Zugriffsrechten bei MySQL ist, weiß ich leider nicht, aber ich stelle mir die verwaltung der User dann doch etwas komplizierter vor.

HTH

Gruß Frank