Online Shop, Spalte 'Menge' mit in DB?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo an Alle,

muss ich die Spalte „Menge“ (Tabelle „Artikel“) mit in der Datenbank erzeugen oder ist es ok wenn ich diese Spalte dann nur auf dem Formular zum Bestellen selbst anlege?! (Kunde trägt ja die Menge ein, wird also nicht mit Daten von DB gefüllt wie z.B. bei Preis od.so)

MfG Sabine L.

#2

Hallo an Alle,

muss ich die Spalte „Menge“ (Tabelle „Artikel“) mit in der
Datenbank erzeugen oder ist es ok wenn ich diese Spalte dann
nur auf dem Formular zum Bestellen selbst anlege?! (Kunde
trägt ja die Menge ein, wird also nicht mit Daten von DB
gefüllt wie z.B. bei Preis od.so)

Du solltest dir im Vorfeld vielleicht mal ein paar Gedanken machen, welche Anforderungen du an die Datenbank hast. Das Datenbank design ist maßgeblich
entscheident für die weitere Entwicklung, etwa von welchem Formular in welche Spalte Daten transferiert werden.

Die Menge der gekauften Artikel ist sicherlich etwas, was mit dem Kunden zusammenhängt. Speicherst du die Menge in die Artikel-Tabelle, so wird ein zweiter Kunde Probleme bekommen, wenn er eine andere Menge bestellt hat. Beim Design von Datenbanken ist man desweiteren sehr darauf bedacht, Daten nicht mehrfach zu speichern. Hast du eine Tabelle, in der der Kundename (beispielweise) etliche male den gleichen Wert hat, so kann das für deine Applikation später einmal kritische Situationen ergeben. Denke mal nur an die Situation, du änderst den Namen, das musst du dann n-mal wiederholen. Und der Kunde mit diesem Namen ist gerade online und bestellt etwas, womit er auch neue Datensätz erzeugt, die dir im ungünstigesten Fall entgehen. Applikationstechnisch ist einsolcher worst-case nur schwer wieder glatt-zu-bügeln.

Ohne deine konkreten Anforderungen zu kennen, mal ein kurzer Vorschlag:

Tabelle Artikel => Stammdaten aller verfügbaren (kaufbaren) Artikel samt Preis
Tabelle Kunden => Stammdaten aller registrierten Kunden
Tabelle Bestellungen => Relation zum Kunden
Tabelle Bestellposten => Relation zu Bestellungen/ Relation zu EINEM Artikel /Menge

Mit diesen vier Tabellen bsit du in der Lage deine Kunden und Artikel zu verwalten. Du kannst nach Bestellungen einen Kunden suchen und hast im Überblick, welche Artikel im Rahmen einer Bestellung geordert wurden.

Vielleicht hilft das ein wenig zur Anregung.

Gruß Markus

#3

hmmm… kommt drauf an wie Du die Bestellungen übermittelt haben willst.

Möglichkeit 1. via Mail an eine Sammeladresse --> dann brauchst Du nicht zwingend eine Spalte in der Form.

Möglichkeit 2. über Auswertung einer Tabelle --> dann brauchst Du es schon.

Ich persönlich würde die Spalte aufjedenfall mit reinnehmen, selbst wenn Du später „nur“ mal auswerten willst, was du wann, wieoft, mit welchem Ertrag verkauft hast.

gruß
Andreas

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

mh okay…hatte schon vor die Bestellung über Mail zu machen, aber dein Vorschlag ist gut,hab ich garnich dran gedacht das ich das Ganze ja mal später auswerten könnte…DANKE!*g*

MfG Sabine L.

hmmm… kommt drauf an wie Du die Bestellungen übermittelt
haben willst.

Möglichkeit 1. via Mail an eine Sammeladresse --> dann
brauchst Du nicht zwingend eine Spalte in der Form.

Möglichkeit 2. über Auswertung einer Tabelle --> dann
brauchst Du es schon.

Ich persönlich würde die Spalte aufjedenfall mit reinnehmen,
selbst wenn Du später „nur“ mal auswerten willst, was du wann,
wieoft, mit welchem Ertrag verkauft hast.

gruß
Andreas

#5

Danke Markus…
GENAU DESWEGEN hab ich ja gefragt, weil mir das Ganze mit der Menge in DB speichern komisch vor kam.

Die tabellen, die du vorschlägst, hab ich schon notiert, nur die Tabelle Bestellposten nicht…

Könntest du mir viell.noch genauer erklären, welche Spalten du in diese Tabelle machen würdest und wie die Beziehung unter den Tabellen aussehen könnte?

MfG Sabine L.

Du solltest dir im Vorfeld vielleicht mal ein paar Gedanken
machen, welche Anforderungen du an die Datenbank hast. Das
Datenbank design ist maßgeblich
entscheident für die weitere Entwicklung, etwa von welchem
Formular in welche Spalte Daten transferiert werden.

Die Menge der gekauften Artikel ist sicherlich etwas, was mit
dem Kunden zusammenhängt. Speicherst du die Menge in die
Artikel-Tabelle, so wird ein zweiter Kunde Probleme bekommen,
wenn er eine andere Menge bestellt hat. Beim Design von
Datenbanken ist man desweiteren sehr darauf bedacht, Daten
nicht mehrfach zu speichern. Hast du eine Tabelle, in der der
Kundename (beispielweise) etliche male den gleichen Wert hat,
so kann das für deine Applikation später einmal kritische
Situationen ergeben. Denke mal nur an die Situation, du
änderst den Namen, das musst du dann n-mal wiederholen. Und
der Kunde mit diesem Namen ist gerade online und bestellt
etwas, womit er auch neue Datensätz erzeugt, die dir im
ungünstigesten Fall entgehen. Applikationstechnisch ist
einsolcher worst-case nur schwer wieder glatt-zu-bügeln.

Ohne deine konkreten Anforderungen zu kennen, mal ein kurzer
Vorschlag:

Tabelle Artikel => Stammdaten aller verfügbaren (kaufbaren)
Artikel samt Preis
Tabelle Kunden => Stammdaten aller registrierten Kunden
Tabelle Bestellungen => Relation zum Kunden
Tabelle Bestellposten => Relation zu Bestellungen/ Relation
zu EINEM Artikel /Menge

Mit diesen vier Tabellen bsit du in der Lage deine Kunden und
Artikel zu verwalten. Du kannst nach Bestellungen einen Kunden
suchen und hast im Überblick, welche Artikel im Rahmen einer
Bestellung geordert wurden.

Vielleicht hilft das ein wenig zur Anregung.

Gruß Markus

#6

Danke Markus…
GENAU DESWEGEN hab ich ja gefragt, weil mir das Ganze mit der
Menge in DB speichern komisch vor kam.

Die tabellen, die du vorschlägst, hab ich schon notiert, nur
die Tabelle Bestellposten nicht…

Könntest du mir viell.noch genauer erklären, welche Spalten du
in diese Tabelle machen würdest und wie die Beziehung unter
den Tabellen aussehen könnte?

Kunden.KundenNr => eindeutige Zahl (primary key)
…
Artikel.ArtikelNr => eindeutige Zahl (primary key)
Artikel.Preis

Bestellung.KundenNr ( + index KundenNr / Nr )
Bestellung.Nr (+ primray key)

BestellPosten.BestellungNr
BestellPosten.ArtikelNummer
BestellPosten.Menge
Bestellposten.Summe

In die Tabelle BestellPosten schreibst du Anzahl der Artikel und resultierender Gesamtpreis. Wenn du die Preise in der Artikeltabelle einmal änderst, hat das so keine Auswirkungen auf gespeicherte Bestellungen.

Sobald ein Artikel Bestandteil einer Bestellung geworden ist, darf er nicht mehr gelöscht werden. Willst du den Artikel aus dem Sortiment nehmen, verwendest du am besten eine zusätzliche Spalte unter Artikel => Artikel.ImSortiment … Kunden bekommen nur Artikel angezeigt, die im Sortiment enthalten sind.

Tabellen-Beziehungen:

BestellPosten : Bestellungen
=> n:1
=> Bestellung kann beliebig viele Posten haben
=> ein Posten ist genau einer Bestellung zugeordnet

BestellPosten : Artikel
=> 1:n
=> ein Posten verweist auf genau einen Artikel
=> ein Artikel kann von unterschiedlichen Posten verwendet werden

Bestellungen : Kunden
=> n:1
=> ein Kunde kann beliebig viele Bestellungen haben
=> eine Bestellung ist genau einem Kunden zugeordnet

Gruß Markus

#7

ABER…
Ahja,aber etwas versteh ich nich ganz…

ich habe glaub ich mal gelernt, das in einer Zwischentabelle (wie hier Bestellung) kein Primärschlüssel sein darf.

Du hast doch aber einen?! oder was heist +primary key

ich dachte das dort nur die zwei fremdschlüssel reinkommen (KundenNr+ArtikelNr)

???
MfG Sabine L.

Kunden.KundenNr => eindeutige Zahl (primary key)
…
Artikel.ArtikelNr => eindeutige Zahl (primary key)
Artikel.Preis

Bestellung.KundenNr ( + index KundenNr / Nr )
Bestellung.Nr (+ primray key)

BestellPosten.BestellungNr
BestellPosten.ArtikelNummer
BestellPosten.Menge
Bestellposten.Summe

In die Tabelle BestellPosten schreibst du Anzahl der Artikel
und resultierender Gesamtpreis. Wenn du die Preise in der
Artikeltabelle einmal änderst, hat das so keine Auswirkungen
auf gespeicherte Bestellungen.

Sobald ein Artikel Bestandteil einer Bestellung geworden ist,
darf er nicht mehr gelöscht werden. Willst du den Artikel aus
dem Sortiment nehmen, verwendest du am besten eine zusätzliche
Spalte unter Artikel => Artikel.ImSortiment … Kunden
bekommen nur Artikel angezeigt, die im Sortiment enthalten
sind.

Tabellen-Beziehungen:

BestellPosten : Bestellungen
=> n:1
=> Bestellung kann beliebig viele Posten haben
=> ein Posten ist genau einer Bestellung zugeordnet

BestellPosten : Artikel
=> 1:n
=> ein Posten verweist auf genau einen Artikel
=> ein Artikel kann von unterschiedlichen Posten verwendet
werden

Bestellungen : Kunden
=> n:1
=> ein Kunde kann beliebig viele Bestellungen haben
=> eine Bestellung ist genau einem Kunden zugeordnet

Gruß Markus

#8

Ahja,aber etwas versteh ich nich ganz…

ich habe glaub ich mal gelernt, das in einer Zwischentabelle
(wie hier Bestellung) kein Primärschlüssel sein darf.

Du hast doch aber einen?! oder was heist +primary key

ich dachte das dort nur die zwei fremdschlüssel reinkommen
(KundenNr+ArtikelNr)

Bestellung ist nicht nur eine Zwischentabelle, sie bildet einen Bestandteil
der Realwelt - eine Bestellung - ab. Eine Bestellung ist durch eine Nr eindeutig gemacht => primary key. Zudem ist eine Bestellung immer einem Kunden zugeordnet. Für diese Zuordnung selbst benötigst du hier keinen Index. Sicherlich möchtest du in deiner Applikation einem Kunden erlauben, Einsicht in alle seine Bestellungen zu geben. Hierfür musst du alle Bestellungen suchen, die der Kunde einmal getätigt hat. Da ein Index auf Bestellung.KundenNr nicht eindeutig ist, habe ich das Feld Bestellung.Nr mit in den Index aufgenommen.

Markus

#9

achso ok.
bin gerade leicht verwirrt…trotz alle dem…was ist dann mein fremdschlüssel??

und ähm in die Tabelle Bestellung habe ich Datum, AnzArtikel und Gesamtpreis aufgenommen-- geht das nicht? weil du die in der tabelle Bestellposten hast…
(in Tabelle Bestellung hast du nur die KundenNr und BestellungNr??mehr nich?)

MfG Sabine L.

Bestellung ist nicht nur eine Zwischentabelle, sie bildet
einen Bestandteil
der Realwelt - eine Bestellung - ab. Eine Bestellung ist durch
eine Nr eindeutig gemacht => primary key. Zudem ist eine
Bestellung immer einem Kunden zugeordnet. Für diese Zuordnung
selbst benötigst du hier keinen Index. Sicherlich möchtest du
in deiner Applikation einem Kunden erlauben, Einsicht in alle
seine Bestellungen zu geben. Hierfür musst du alle
Bestellungen suchen, die der Kunde einmal getätigt hat. Da ein
Index auf Bestellung.KundenNr nicht eindeutig ist, habe ich
das Feld Bestellung.Nr mit in den Index aufgenommen.

Markus

#10

achso ok.
bin gerade leicht verwirrt…trotz alle dem…was ist dann mein
fremdschlüssel??

KundenNr,BestellNr ist dein Fremdschlüssel zu Kunden

und ähm in die Tabelle Bestellung habe ich Datum, AnzArtikel
und Gesamtpreis aufgenommen-- geht das nicht? weil du die in
der tabelle Bestellposten hast…

Du musst dir einmal überlegen, was du da ablegen möchtest. Eine Bestellung besteht aus genau einer Zeile in der Tabelle Bestellung. Die Anzahl von was möchtest du hier ablegen?
Die Rechnungssumme geht aus der Anzahl der einzelnen Artikel, jeweils Menge x Preis hervor. Diese stehen aber in den Rechnungsposten. Jeder Posten verweist auf einen Artikel, gibt Anzahl und Summen-Preis an.

Wenn du mal an den Supermarkt denkst, wird das hier genauso gemacht. Auf dem Kassenbon steht in jeder Zeile einmal der Artikelname, einmal die Anzahl und die Summe (ggf. auch noch der Einzelpreis).

Wenn du dir nicht sicher bist, schreib dir die Tabellen einfach mal auf Papier und schreibe einige Einträge herein. Da wird die Logik schnell klar. Ich nehme mir oft ein Access Datenbank zur Hand, um das Szenario mal durchzuspielen.

Markus

#11

aahhhhh jetzt ok …Vielen Dank!
schön dass einem hartnäckigen fall wie mir trotzdem geholfen wird*G*

MfG Sabine L.
p.s. (BestellDatum kommt nich irgendwo mit rein?)

KundenNr,BestellNr ist dein Fremdschlüssel zu Kunden

Du musst dir einmal überlegen, was du da ablegen möchtest.
Eine Bestellung besteht aus genau einer Zeile in der Tabelle
Bestellung. Die Anzahl von was möchtest du hier ablegen?
Die Rechnungssumme geht aus der Anzahl der einzelnen Artikel,
jeweils Menge x Preis hervor. Diese stehen aber in den
Rechnungsposten. Jeder Posten verweist auf einen Artikel, gibt
Anzahl und Summen-Preis an.

Wenn du mal an den Supermarkt denkst, wird das hier genauso
gemacht. Auf dem Kassenbon steht in jeder Zeile einmal der
Artikelname, einmal die Anzahl und die Summe (ggf. auch noch
der Einzelpreis).

Wenn du dir nicht sicher bist, schreib dir die Tabellen
einfach mal auf Papier und schreibe einige Einträge herein. Da
wird die Logik schnell klar. Ich nehme mir oft ein Access
Datenbank zur Hand, um das Szenario mal durchzuspielen.

Markus

#12

aahhhhh jetzt ok …Vielen Dank!
schön dass einem hartnäckigen fall wie mir trotzdem geholfen
wird*G*

MfG Sabine L.
p.s. (BestellDatum kommt nich irgendwo mit rein?)

Ich habe in meinem Vorschlag nur die essentiell wichtigigen Felder angerissen, die notwendig sind, um eine saubere Relation zum implementieren. In Bestellungen kann du natürlich weitere Felder, wie Datum/Status/Vermerk angeben. In BestellPosition entsprechend noch den Einzelpreis, einen Rabatt (wenn vorgesehen), ggf. auch noch mal die Artikelbeschreibung (falls die sich im Artikelstamm häufig ändern wird).

Abhängig davon musst du dir überlegen, wie du mit deinen Artikeln umgehen möchtest. In meinem Vorschag wird der Artikel per Relation eingebunden, d.h. Änderungen am Namen haben somit Auswirkungen auf bestehende Rechnungen. Dem kannst du einfach entgegenwirken, indem du definierst: die Artikelbezeichnung eines bestehenden Artikel darf nicht geändert werden, stattdessen muss der „alte“ Artikel aus dem Sortiment entnommen und unter der neuen Bezeichnung mit einer neuen Artikelnummer eingetragen werden.

Alternativ kannst du dir auch die Artikelrelation sparen und kopierst den kompletten Artikel in den Bestellposten (also Name, und ggf weitere Felder). Hat den Vorteil, dass es einfacher zu verwalten ist, sprich fehlertoleranter wird. Hat aber auch den Nachteil, dass deine Artikel in zig Kopien in der Datenbank existieren und somit natürlich wesentlich mehr Platz in Anspruch nehmen. Wenn dein online-shop floriert, wirst du einen Unterschied in der Performance wahrnehmen, ausserdem sind Backup aufwendiger, da ja viel mehr Daten ghesichert werden müssen.

Ich bevorzuge daher den ersten Vorschlag. Du hast für deine Datenbank aber die freie Wahl und darfst der Kreativität freien Lauf lassen! :o)

Gruß Markus

#13

Also hier nochmal um Fehler zu vermeiden meine Tabellen:

__KUNDE__
KundenNr -Primary Key
Nachname
Vorname
Firma
Straße
…

__BESTELLUNG__
BestellungNr -Primary Key
KundenNr -Secondary key ->(Frage:schreibe i.das auch so in einer Dokumentation?also nicht etwa Kunde.KundenNr?)
Datum

__ARTIKEL__
ArtikelNummer -Primary Key
Artikelbez
Hersteller
ArtikelNr
Preis
ImSortiment

__BESTELLPOSTEN__
BestellungNr -Secondary key
ArtikelNr —>was ist hiermit???(ist das die ArtikelNummer-Primary oder ArtikelNr)
Preis
Rabatt
Menge
Gesamtpreis

Passt das so?

MfG Sabine L.

#14

Also hier nochmal um Fehler zu vermeiden meine Tabellen:

__KUNDE__
KundenNr -Primary Key
Nachname
Vorname
Firma
Straße
…

Okay

__BESTELLUNG__
BestellungNr -Primary Key
KundenNr -Secondary key ->(Frage:schreibe i.das auch so in
einer Dokumentation?also nicht etwa Kunde.KundenNr?)
Datum

Am besten schriebst du die Indizes separat auf. Sobald du mehr als eine Spalte auf einen Index setzt, hast du mit der Darstellung Probleme.

primary-key: BestellungNr
index: KundenNr,BestellungNr

__ARTIKEL__
ArtikelNummer -Primary Key
Artikelbez
Hersteller
ArtikelNr

Der ist doppelt

Preis
ImSortiment

__BESTELLPOSTEN__
BestellungNr -Secondary key

PostenNr

ArtikelNr —>was ist hiermit???(ist das die
ArtikelNummer-Primary oder ArtikelNr)
Preis
Rabatt
Menge
Gesamtpreis

primary-key: BestellungNr, PostenNr

Passt das so?

Sieht so gut aus!

Markus

#15

__BESTELLUNG__
BestellungNr -Primary Key
KundenNr -Secondary key ->(Frage:schreibe i.das auch so in
einer Dokumentation?also nicht etwa Kunde.KundenNr?)
Datum

Am besten schriebst du die Indizes separat auf. Sobald du mehr
als eine Spalte auf einen Index setzt, hast du mit der
Darstellung Probleme.

also das mit dem index kapier ich nich,hab wohl gepennt damals :frowning:

primary-key: BestellungNr
index: KundenNr,BestellungNr

__ARTIKEL__
ArtikelNummer -Primary Key
Artikelbez
Hersteller
ArtikelNr

Der ist doppelt

ähm, ArtikelNummer ist der AutoWert und ArtikelNr z.b. 376-733-490, is nich das gleiche…oder wie meinst du?

Preis
ImSortiment

__BESTELLPOSTEN__
BestellungNr -Secondary key

PostenNr

ok hab ich ergänzt als primary key

ArtikelNr —>was ist hiermit???(ist das die
ArtikelNummer-Primary oder ArtikelNr)
Preis
Rabatt
Menge
Gesamtpreis

primary-key: BestellungNr, PostenNr

wie gleich 2 primary keys?? wieso denn BestellungNr als primary?

Passt das so?

Sieht so gut aus!

Markus

#16

Am besten schriebst du die Indizes separat auf. Sobald du mehr
als eine Spalte auf einen Index setzt, hast du mit der
Darstellung Probleme.

also das mit dem index kapier ich nich,hab wohl gepennt damals

(

Schlüssel/Fremschlüssel verwendest du beim Design von Tabellenstrukturen, um Relationen kenntlich zu machen. Ein Schlüssel muss eindeutig sein, das ist eine Forderung an die Datenbank.

Auf der Datenbank gibt es nun Indizes(Indexe), dazu gehört auch der Primärschlüssel. Ein Index gibt dir einen sortierten Zugriff auf die Daten. Der Index ist vergleichbar mit einem Telefonbuch, hier kannst du anhand des Anfangsbuchstaben direkt die passende Seite aufschlagen. Wäre das telefonbuch nicht nich diesem Schema sortiert (indiziert), müsstest du von nach hinten das komplette Buch nach deiner Adresse durchsuchen.

Ein Index kann eindeutig oder mehrdeutig sein. Verwendest du einen eindeutigen Index, so verbietet dir die Datenbank doppelte Werte abzulegen. Der Primärschlüssen ist ein besonderer Index (bei vielen Datenbanken), für dich ist er aber wie ein eindeutiger Index.

primary-key: BestellungNr
index: KundenNr,BestellungNr

__ARTIKEL__
ArtikelNummer -Primary Key
Artikelbez
Hersteller
ArtikelNr

Der ist doppelt

ähm, ArtikelNummer ist der AutoWert und ArtikelNr z.b.
376-733-490, is nich das gleiche…oder wie meinst du?

Dann ist es okay.

ArtikelNr —>was ist hiermit???(ist das die
ArtikelNummer-Primary oder ArtikelNr)
Preis
Rabatt
Menge
Gesamtpreis

primary-key: BestellungNr, PostenNr

wie gleich 2 primary keys?? wieso denn BestellungNr als
primary?

Nein, es kann nur einen primary key geben. Allerdings darf der aus mehreren Spalten bestehen. Du könntest PostenNr alleine als primary Key anlegen, du hast aber ein Fremdschlüssel auf BestellungNr, PostenNr, d.h. wenn du zu einer dir bekannten Bestellung die Posten suchst, geht das nür über die BestellungNr. Da du mehrere Posten zu einer Betsellung hast, ist das alleine nicht eindeutig. Aus diesem Grund verwendest du als zweite Spalte für den Index (oder Primärschlüssel) die PostenNr. Diese ist eine AutoNumber.

Markus