SQL Onlineshopbestellung - wie am besten bestellte Artikel speichern?

furryhamster

Lt. Commander
Registriert
Okt. 2008
Beiträge
1.098
Hi,

will eine Website mit Bestellsystem schreiben. Wie setze ich das am besten in meiner Datenbank (mysql) um?

Folgendes habe ich mir bisher gedacht:
Tabelle kunden, anreden, bestellungen, artikel

in bestellungen kommen halt die bestellungen rein. Hier wird in einer Spalte die ID von Artikel angegeben. In der Tabelle Artikel gibt es für jeden Artikel eine Spalte, in der pro Eintrag die gewünschte Menge steht.

Problem was ich daran sehe ist, dass ich in der Tabelle artikel extrem viele spalten habe und ich nirgends eine Artikelbeschreibung speichern kann. Brauche also eigentlich eine Tabelle artikel, in dem wirklich nur die Artikel mit id, name, beschreibung gespeichert sind. nur wo und wie speicher ich dann die bestellten Artikel?
 
Sorry habe es etwas falsch gelesen ^^

Ja du brauchst eine Tabelle Artikel in der nur diese Infos stehen.

In der Tabelle Bestellungen traegst du dann die ID vom Kunden ein und die ID des bestellten Artikels + die Menge und den Preis pro Artikel und vllt noch gesamt fuer die Anzahl der Artikel.

Die beiden IDs (Kunde und Artikel) sind Fremdschluessel welche Pflicht sind.
Dazu einen Primaerschluessel welcher die Bestellnummer ist.

Fertig.
 
Zuletzt bearbeitet:
Beschäftige dich am besten mit dem Thema: Relationale Datenbanken
Wenn das ganze nicht nur ein Schulprojekt ist und wirklich ins Netz soll, musst du dich zusätzlich mit Stored Procedures und SQL Injection beschäftigen.
 
Also wenn der Onlineshop nur so zum Spaß ist ok, ansonsten hört sich das "Schreiben" nach bloßem html an mit bisschen javascript wenn überhaupt.
Sowas macht man heutzutage anderst -> J2EE also Struts2 fürs Frontend und Hibernate für das Backend.

Deine Datenbankmodellierung lässt stark zu wünschen übrig. IC3HANDS hat schon das richtige Schlagwort erwähnt. Normalisierung bis zur 3. Stufe reicht aus.

Ansonsten ein Onlineshop hat wesentlich mehr Tabellen als du sie aufführst.
Kunden, Anreden, Bestellungen, Artikel sind zu wenige.
Eine Bestellung hat immer 1...n Bestellpositionen, Ein Artikel kann mit Artikelgruppen verbunden werden, es gibt Hersteller, Images für die Artikel -> extra Tabelle, etc.

Das sind nurn paar wenige.

Such einfach mal nach Normalisierung/ Entity Relationship modellierung da wirsde genug finden unter anderem auch Beispiele zu einem Onlineshop
 
IC3HANDS schrieb:
Sorry habe es etwas falsch gelesen ^^

war schon etwas irritiert wo du meinstest das normalisierung nicht eingehalten (außer evtl bei plz und ort) wurde ^^

Bei deinem Konzept würde für jeden Artikel der bestellt wird ein separater Eintrag in der Tabelle bestellungen erfolgen? d.h. kunde bestellt 10 verschiedene Artikel und somit 10 Einträge? Scheint mir auf den ersten Blick auch noch nicht so sinnvoll, lasse mich aber gerne eines besseren belehren :)

Habe jetzt nochmal drüber nachgedacht und folgendes ist bei rumgekommen:

kunden
id name vorname strasse plz ort telefon eMail

bestellungen
id timestamp erledigt kunden-id bestellteArtikel

Artikel
id name beschreibung Preis

bestellteArtikel
BestellungsId ArtikelID Anzahl

So müsste ich redundanz doch denke überwiegend vermieden haben und ich hab keine Tabelle mit extrem vielen spalten. Wäre dies soweit sinnvoll bzw besser als das Konzept als von dir IC3HANDS?

Fremdschlüssel setze ich einfach mit Constraints um?

Das ganze ist nur ein Studiumprojekt und wird mit Seam umgesetzt (also kein HTML+Javascript^^) um Seam zu erlenen bzw. ein Beispielprojekt zu erstellen. Dennoch sollte es schon halbwegs effektiv/realitätsnah sein
 
Hi,

lies dich bitte wie schon mehrfach gesagt in die Normalisierung ein. Deine Tabelle "Bestellungen"... was steht z.B. in der Spalte "bestellteArtikel", wenn ich mehrere Artikel Bestelle?

Tabellen mit "extrem vielen Spalten" braucht man nur, wenn man für die Tabelle bzw. die Objekte, die damit beschrieben werden, extrem viele Eigenschaften braucht.

Fremdschlüssel sind nicht Constraints! Das ist was vollkommen anderes! Bitte lese dich da erst ein, bevor du das komplett falsch verstehst!

VG,
Mad
 
danke erstmal für eure Bemühungen :)

Madman1209 schrieb:
Hi,

lies dich bitte wie schon mehrfach gesagt in die Normalisierung ein. Deine Tabelle "Bestellungen"... was steht z.B. in der Spalte "bestellteArtikel", wenn ich mehrere Artikel Bestelle?

Fremdschlüssel sind nicht Constraints! Das ist was vollkommen anderes! Bitte lese dich da erst ein, bevor du das komplett falsch verstehst!

VG,
Mad

spontan würd ich behaupten ich weiß was normalisierung ist. wenn mir jemand sagt wo ich gegen eine Regel verstoße (außer das man plz und ort auch separat ablegen könnte) würde ich mich jedoch noch mal damit beschäften. Pro unterschiedlichem bestellten Artikel wird in meinem Konzept ein eigener Eintrag (neue Zeile) in "bestellteArtikel" geschrieben.

Madman1209 schrieb:
Fremdschlüssel sind nicht Constraints! Das ist was vollkommen anderes! Bitte lese dich da erst ein, bevor du das komplett falsch verstehst

Ich kenne den Unterschied soweit. Laut diesem Artikel brauch man Fremdschlüssel nur nicht extra in mysql definieren, da es nur als "Erinnerung" dient. Um jedoch Fremdschlüssel einzuhalten könnte man dies auch Datenbanktechnisch mit Constraints sicherstellen (z.B. kundenid muss in tabelle kunde existieren)

Falls ich doch einen Denkfehler habe bitte auch mitzuteilen wo und nicht nur auf normalisierung verweisen. Nach jetzigem wissen würde ich behaupten dass ich diese eingehalten habe
 
Also Fremdschlüssel sind schon eine Art von Constraints nur eben eine ganz besondere man sagt ja auch "Foreign Key Constraint".

Da es sich um ein Studiumsprojekt handelt finde ich es etwas schwach so an die Aufgabe heranzugehen. Hattet ihr denn schon eine Datenbankvorlesung zu Normalisierung etc. ? Laut dem was du lieferst nicht, denn sonst würdest du die Frage auch nicht stellen.

Scheinbar weist du nämlich nicht was Normalisierung bedeutet. Sonst hättest du sie angewant und nicht den folgenden Fehler gemacht.

bestellungen
id timestamp erledigt kunden-id bestellteArtikel

bestellteArtikel
BestellungsId ArtikelID Anzahl

Was genau daran falsch ist darfst du mal nachlesen ;) Sonst bringt das ja nichts, wenn man dir alles vorsagt.
 
Hi,

@NuminousDestiny

Du schreibst "Also Fremdschlüssel sind schon eine Art von Constraints nur eben eine ganz besondere man sagt ja auch "Foreign Key Constraint".

Ist zwar generell eine absolut korrekte Aussage, da gebe ich dir recht. Aber ein Schlüssel ist ein Schlüssen und ein Contraint ein Constraint. Punkt. Dass es Schlüsselconstraints gibt stellt das weder in Frage noch widerspricht es. Ein Schlüssel sagt der Datenbank, nach welchem Wert bzw. welcher Spalte indiziert werden soll. Ein Constraint ist einfach nur eine Bedingung, was erlaubt ist und was nicht bzw. was passiert, wenn...

Guter Stil ist es so oder so, einen Fremdschlüssel auch als solchen zu deklarieren, wenn ich ihn verwende. Dass man das Verhalten auch mit Contraints irgendwie nachbauen kann stimmt sicher - ich kann auch mit dem Anlasser in die Arbeit fahren ;)

Ich will dich damit nicht belehren, deine Aussage ist ja absolut richtig, aber dem TE hilft es glaube ich gerade am Anfang und bei seinem derzeitigen Wissensstand, wenn er da alles piekfein macht und erklärt bekommt :) Wollen wir uns darauf so einigen? :)

spontan würd ich behaupten ich weiß was normalisierung ist. wenn mir jemand sagt wo ich gegen eine Regel verstoße (außer das man plz und ort auch separat ablegen könnte) würde ich mich jedoch noch mal damit beschäften.

Daher war ja meine Frage:

Deine Tabelle "Bestellungen"... was steht z.B. in der Spalte "bestellteArtikel", wenn ich mehrere Artikel Bestelle?

Die hast du so noch nicht beantwortet. Was steht also in der Spalte "bestellteArtikel" wenn ich mehrere Artikel bei einer Bestellung habe?

VG,
Mad
 
Zuletzt bearbeitet:
Ja Schlüssel sind synonyme für eine spezielle Form ;)
Da sich der Sprachgebrauch so entwickelt hat sollte man auch dabei bleiben schon klar.
Die Informatik und die Welt der Akronyme gekreuzt mit den Synonymen bringt jeden Informatiker mal dazu ausm Fenster zu springen, egal ob früher oder später. :-D
 
ja wir hatten schon datenbanken als vorlesungen. ich glaube auch ich weiß jetzt worauf hier hinaus wollt...^^

ich vermute ihr wollt mir folgendes sagen: ich muss "bestellteArtikel" in der Tabelle bestellungen weglassen und hätte so in der Tabelle "bestellteArtikel" einen zusammengesetzten primary key (d.h. bestellungsId kann in dieser Tabelle mehrmals vorkommen). Besser wäre wahrscheinlich noch, dass ich zusätzlich eine Id für die Tabelle "bestellteArtikel" vergebe.

Richtig so?

Zusätzlich noch Fremdschlüssel deklarieren und ich vermute mal die Primary keys folgedessen auch (autoincrement allein wird dann denke auch nicht reichen)
 
Das mit der Tabelle Bestellungen stimmt.
BestellteArtikel also Bestellpositionen kannst du entweder wie du sagtest ne ID verpassen oder nen zusammengesetzen Primary Key mittels ArtikelID und BestellungID erstellen, da dieser ja eindeutig wäre.
Bei der 1. Lösung benötigt du Constraints, dass ArtikelID mit BestellungID nur 1x vorkommen darf. Bei 2. Lösung erübrigt sich das.

Bei mir stellt sich allerdings die Frage, wenn ihr schon eine DB Vorlesung hattet, bezog sich diese nur auf SQL bzwl Mathematischen Relationen mittels ner Pseudo Sprache, der Name fällt mir nichtmehr ein :S
Oder ging die Vorlesung auch über DB Design mit EER Modell, Normalisierung? Weil wenn ihr Normalisierung behandelt hattet, dann ist es scwer zu verstehen, warum du da so unsicher bist. Denn schwer ist das alles nicht.
 
NuminousDestiny schrieb:
Bei mir stellt sich allerdings die Frage, wenn ihr schon eine DB Vorlesung hattet, bezog sich diese nur auf SQL bzwl Mathematischen Relationen mittels ner Pseudo Sprache, der Name fällt mir nichtmehr ein :S
Oder ging die Vorlesung auch über DB Design mit EER Modell, Normalisierung? Weil wenn ihr Normalisierung behandelt hattet, dann ist es scwer zu verstehen, warum du da so unsicher bist. Denn schwer ist das alles nicht.

Kam alles drin vor. Problem war denke eher der innere Schweinehund. Wollte das Tabellenkonzept beim Anlegen der Tabellen machen und hab nicht groß (bzw. zu wenig) drüber nachgedacht. Durch meine erste (unsinnige) Idee die Artikel in Spalten zu verteilen entstand dann dieser Post. Ich gelobe Besserung und werde demnächst vor dem posten mehr über das Tabellenkonzept nachdenken :heilig:
 
Entgegen einiger Meinungen hier, muss man nicht direkt immer mit Kanonen auf Spatzen schießen.
Du kannst das ruhig mit PHP und MySQL machen. Jedoch solltest du dir im Vorfeld einige Informationen zur sauberen Modellierung der Datenbank und zu Trennung zwischen HTML und PHP Code einholen.
z.B. hier im Forum wie du es schon angedeutet hast.
Allgemein sollte es in deiner Datenbank mindestens folgende Objekte geben:
Kunde, Artikel und Bestellung.

Gruß
 
Bauergiesen schrieb:
Entgegen einiger Meinungen hier, muss man nicht direkt immer mit Kanonen auf Spatzen schießen.
Du kannst das ruhig mit PHP und MySQL machen. Jedoch solltest du dir im Vorfeld einige Informationen zur sauberen Modellierung der Datenbank und zu Trennung zwischen HTML und PHP Code einholen.
z.B. hier im Forum wie du es schon angedeutet hast.
Allgemein sollte es in deiner Datenbank mindestens folgende Objekte geben:
Kunde, Artikel und Bestellung.


Da ich mit diesem Webshop Seam erlernen möchte kommt PHP nicht in Frage. Denke ich bau das Datenbanksystem jetzt wie oben beschrieben auf.

Danke nochmal an alle
 
Zurück
Oben