Wie soll ich daten in datenbank speichern?

[Alex]

hallo,

ich kenn mich mit datenbanken noch nicht so gut aus.

1. wenn sich jetzt kunden bei mir registrieren, will ich sie in einer datenbank speichern, aber ich weiss nicht ob ich für jeden kunden eine neue tabelle erzeugen oder alle kunden in einer tabelle unterbringen soll??

2. wenn ich jetzt artikelbeschreibungen für ein warenkorb in der datenbank speichern will, sollte ich wohl eine neue tabelle erzeugen und in diese tabelle spalten reinbauen für die beschreibungen, preise,..., oder???

danke im vorraus

[Ole]

hi

1. wenn sich jetzt kunden bei mir registrieren, will ich sie in einer datenbank speichern, aber ich weiss nicht ob ich für jeden kunden eine neue tabelle erzeugen oder alle kunden in einer tabelle unterbringen soll??

für alle kunden zusammen eine tabelle und pro kunde ein datensatz

2. wenn ich jetzt artikelbeschreibungen für ein warenkorb in der datenbank speichern will, sollte ich wohl eine neue tabelle erzeugen und in diese tabelle spalten reinbauen für die beschreibungen, preise,..., oder???

genau.

so long
ole
(8-)>

[Henning]

Hallo,

1. wenn sich jetzt kunden bei mir registrieren, will ich sie in einer datenbank speichern, aber ich weiss nicht ob ich für jeden kunden eine neue tabelle erzeugen oder alle kunden in einer tabelle unterbringen soll??

für alle kunden zusammen eine tabelle und pro kunde ein datensatz

Das kann man nicht so pauschal sagen. Es hängt davon ab, welche Daten zu einem Kunden existieren sollen. Dadurch kann man auch mehrere Tabellen verwenden, wenn man Redundanz vermeiden will.
Sollen z.B. die bisherigen Bestellungen gespeichert werden oder existiert der Kunde nur solange eine Bestellung vorliegt?

Gruß,
Henning

[Alex]

Sollen z.B. die bisherigen Bestellungen gespeichert werden oder existiert der Kunde nur solange eine Bestellung vorliegt?

nein die bestellungen werden gar nicht gespeichert. der kunde registriert sich und bleit dann immer gespeichert. von einer bestellung hängt das nicht ab.

aber ich habe jetzt glaub ich alles verstanden.

vielen dank für eure hilfe.

[wahsaga]

hi,

für alle kunden zusammen eine tabelle und pro kunde ein datensatz
Das kann man nicht so pauschal sagen. Es hängt davon ab, welche Daten zu einem Kunden existieren sollen.

aber die aussage, dass man _nicht_ für jeden kunden eine eigene tabelle anlegt, die kann man wohl so ziemlich pauschal so stehen lassen.

es st der _sinn_ einer datenbank, daten von gleichem format auch am gleichen ort abzulegen.

gruss,
wahsaga

[Henning]

Hallo,

für alle kunden zusammen eine tabelle und pro kunde ein datensatz
Das kann man nicht so pauschal sagen. Es hängt davon ab, welche Daten zu einem Kunden existieren sollen.
aber die aussage, dass man _nicht_ für jeden kunden eine eigene tabelle anlegt, die kann man wohl so ziemlich pauschal so stehen lassen.

Ich bezog mich auf den ganzen Satz. Damit meinte ich das es nicht unbedingt Sinn macht alle Daten eines Kunden in einer Tabelle zu speichern. Sondern z.B. Addressen und Bestellungen des Kunden zu trennen.

Gruß,
Henning

[Rouven]

Hi,

vom mathematischen Standpunkt (in kurz):
Eine Tabelle ist eine Menge gleichartiger Objekte (auch als Datensätze bekannt). Die Spalten repräsentieren dabei die Eigenschaften dieser Objekte. Für deine Kunden heißt das also:
Du hast eine Tabelle 'Kunden', in der du eine Menge von Kunden mit bestimmten Eigenschaften wie Name, Vorname, Strasse, PLZ, ... verwaltest.
Für deine Artikel gilt etwas ähnliches.
Für jeden Kunden eine neue Tabelle zu erzeugen bringt nichts, du würdest nicht ihre "Gleichartigkeit" ausnutzen sondern sie so behandeln, als wären sie alle volkommen unterschiedlich - Dies würde darauf hinauslaufen, dass du in jeder Tabelle nur einen Datensatz nämlich genau diesen Kunden hast, was nicht Sinn der relationalen Datenbank ist...

MfG
Rouven

[fastix®]

Moin!

1. ... aber ich weiss nicht ob ich für jeden kunden eine neue tabelle erzeugen oder alle kunden in einer tabelle unterbringen soll??
2. ... artikelbeschreibungen für ein warenkorb in der datenbank speichern will....

Ich bitte Dich ernstlich darum, das Du Dir zunächst überlegst, ob es sinnvoll ist ausgerechnet mit einem Webshop (so liest sich das nämlich...) erste Schritte beim Enwickeln von Datenbanklösungen zu unternehmen (auch das leist sich so). Wenn der nur "für's stille Kämmerlein" gedacht ist: ok. Wenn Du der aber irgendwo, irgendwie in der Betrieb gehen soll, dann muß ich Dich warnen: So etwas ist sehr empfindlich und zwar in verschiedenen Richtungen:

• Es werden Verträge geschlossen. Das ist schon heikel. Was, wenn ein Kunde die Bestellungen manipulieren kann?
• Es werden (eventuell) Zahlungen abgewickelt und hierfür Daten ausgetauscht: Was, wenn die irgendwie unsicher gehalten werden und dritte Einblick nehmen?
• Es gibt eine Menge juristischer Probleme und Pflichten: (Impressum, Preisauszeichnung, Preisklarheit, Amazon- Patente.... )

Natürlich kannst Du mit Deinem Kunde einen Haftungsausschluß vereinbaren: aber, wenn Du ohne die erforderlichen Vorkenntisse in das Projekt reingehst, dann ist das grob fahrlässig. Und wenn Du grobe Fahrlässigkeit aus der Haftung heraushalten willst, werden und sollten Deine Kunden wohl "Nein" sagen.

Ich muß Dich wirklich bitten den Shop für das stille Kämmerlein zu machen oder aber Dir ein(ige) andere(s) Projekt(e) zu suchen, bei dem Du was über Datenbanken lernen kannst:

z.B.
Schon mal ein Forum geschrieben, bei dem sich die Benutzer mit Name und Passwort anmelden müssen, und das ganze richtig gemacht, nämlich so, dass es "sicher" ist?

Das wäre eine Vorstufe...
Danach baue etwas, was es Deinen Besuchern erlaubt eigene Stylesheets zu verwenden und sich gegenseitig Nachrichten zu schicken, die auf dem Server liegen. Du darfst Funktionen hinzufügen.

Dann baue einen Kalender mit der Möglichkeit Termine hinzuzufügen, zu löschen, zu editieren...

Baue ein einfaches CMS, mit dem Du eine Webzeitung "herausgeben" kannst. Vergebe dabei die "Rollen" Autor, Lektor, Chefredakteur. Achte auf die Rechte: Autor darf nur seine Artikel schreiben, bis sie veröffentlicht sind. Lektor darf Artikel redigieren, bis sie veröffentlicht sind, Chefredakteur darf Artikel immer schreiben, immer redigieren und: er darf sie veröffentlichen, zurückziehen und anderen Autoren übergeben.
Erweitere dies auf verschiedene Redakteure, die für bestimmte Bereiche zuständig sind. Denke an die Rechte.
Mach Dir Gedanken darüber, wie Du deren Benutzerkennungen sicher überträgst und speicherst...

Das funktioniert alles prächtig?
Beginne über einen Webshop nachzudenken.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®