Datenbank entwerfen

mrdelete

Grünschnabel
hallo

Ich beginne mit der Programmierung eines komfortablen onlineShop.
Ich habe bereits mehrere kleine Projekte in MySQL & PHP realisiert.
Dabei zeigte sich oft im Verlauf der Entwicklung, dass die Datenbank zu wenig
durchdacht angelegt wurde. Also zum Beispiel die Tabellen zu wenig getrennt und nur durch Keys verbunden.
Kennt jemand von euch eine gute Page/Tutorial o.ä. wie man am besten
eine Datenbank entwirft (möglichst allgemein Formuliert)!

Vielen Dank
 
Da hast du dich ja an etwas wirklich Schwieriges rangewagt.

Es kommt ganz darauf an wie komplex der Shop werden will. Je allgemeiner, desto schwieriger.

Bedenke:
- verschiedene Produkte benötigen verschiedene Zusatzangaben
(z.B. Kleidung: Größe, Fabre, Stoff etc.), die ja dann auch optional zu verwalten sind
- Rabatte (Klassifizierung in verschieden Rabattstufen)
- Versandkosten

Ich würde erst einmal eine Aufteilung in Produktklassen (jetzt rein formell ohne Coding) in Erwägung ziehen. Und da wird das Ganze sehr kompliziert.
Natürlich brauchst du dann auch nested sets für die gesamte Produktpalette.

Ich wollte auch einmal einen "Shop-für-alles" programmieren, habe es aber bald aufgegeben.
 
Naja...

dann frag mal jeden "Programmierer". Und frag "Informatiker". Du erhältst da ganz verschiedene Antworten. Ich habe aus der Perspektive der Informatik geantwortet. Natürlich ist der Code simpel. Aber denk dich mal in die Problematik rein.

Ein guter Online-Shop erfordert ein Projektmanagement erster Güte!
 
Zuletzt bearbeitet:
Natürlich muss ein online-Shop gut durchdacht werden, aber so eine grosse Sache ist das nun wirklich nicht...Zähle mich übrigens auch als Informatiker und Programmierer...:)
 
Mein Gott Snuu, hast du einen schlechten Tag, oder pöbelst du immer so rum? Ich hoffe dein staatliches Zertifikat hängt noch schön an der Wand.

Nun, ich will einen Shop der folgendes leistet:

beliebige Klassen von Produkten, die alle erdenklichen Kriterien von produkten aufnehmen können: beispielsweise Größen (in S, M, L, XL und Werten), Farben, Maße, Zubehör.
evtl. auch obligatorisch, evtl. Preisänderung (prozentual oder fest), evtl. Lagerrückfrage, evtl. nach Wahl ein Verweis auf ein anderes Produkt (sprich andere Produktnummer).
Alles natürlich administrierbar, sodass auch ein Tante-Emma-Laden sein Online-Angebot reinstellen kann.

Rabatte. Gestaffelt nach Mengen, Sonderangebote natürlich, bestimmte Benutzerklassen, die andere Rabatte erhalten.

Da wir ein Online Shop wollen, will das natürlich auch mit etlichen Boni versehen sein, wie Empfehlungen ähnlicher Produkte.

Soweit erstmal. Wenn du das so lächerlich findest, dann präsentiere mir doch einfach mal in groben Zügen einen Lösungsansatz.

Mein Gott, dass sich die Leute hier immer so aufblasen müssen. Der Ton hier in dem Forum ist wirklich unmöglich, gerade weil einige ihr Ego su pushen müssen.

Und es gilt dasselbe wie in einem anderen Posting von mir.

Nachlesen, NachDENKEN. Danke
 
Ach nee,

die Datenbankstruktur ist mir schon klar. Verbinde das erst einmal. Denk auch daran: ich möchte ein Auto verkaufen und die passende Kleidung (extreme Werte)
 
snuu hat gesagt.:
Dass ich Dir binnen 10 Minuten kein ausgefeiltes RDM Liefern kann versteht sich von selbst. Hier aber die grobe Datenstruktur:

Produkte
-----------------------
PRODUKT_ID
BEZEICHNUNG
EP
UVP
IST_SONDERANGEBOT
...
OK. klar.
Natürlich noch:
KUNDENGRUPPEN_ID
Manche Kunden sollen ja nicht alle Produkte sehen können.
Kategorien
-----------------------
KATEGORIE_ID
KATEGORIE_VORGAENGER_ID
BEZEICHNUNG
...
KUNDENGRUPPEN_ID
Siehe oben.
Klar unsere lieben Nested Sets :)
PRODUKTE_KATEGORIEN
-----------------------
PRODUKT_ID
KATEGORIE_ID


KUNDEN
-----------------------
KUNDEN_ID
KUNDENGRUPPEN_ID
Name
Vorname
...


KUNDENGRUPPE
-----------------------
KUNDENGRUPPEN_ID
BEZEICHNUNG
...

RABATT
-----------------------
PRODUKT_ID
KUNDENGRUPPEN_ID
RABATT_WERT
PROZENTUAL


MENGENRABATT
-----------------------
SCHWELLWERT
RABATT_WERT
RABATT_PROZENTUAL

PRODUKTVERWEISE
-----------------------
PRODUKT_ID_VON
PRODUKT_ID_ZU
BENÖTIGT
NICHT_MIT

PRODUKTKRITERIEN
-----------------------
PRODUKTKRITERIEN_ID
BEZEICHNUNG
Was uns zu der Administration führt also:
TYP_KRITERIUM
PRODUKTKRITERIEN_PRODUKT
-----------------------
PRODUKTKRITERIEN_ID
PRODUKT_ID
WERT


PRODUKT_EMPFEHLUNGEN
-----------------------
PRODUKT_ID
PRODUKT_ID_EMPFEHLUNG


BESTELLUNG
-----------------------
BESTELL_ID
KUNDEN_ID
...


BESTELLPOSITIONEN
-----------------------
PRODUKT_ID
MENGE
...


snuu
Ich editier gleich nochmal weiter.
Übrigens: mit aufgeben meinte ich nicht, dass ich nicht in der Lage war das Ding zu coden. Ich hatte nur keine Zeit.
Und du wirst das selbst mit staatlichem Zertifikat nicht so schnell aus dem Ärmel schütteln. Glaub mir.
Immerhin muss das auch schön zu administrieren sein. Und da habe ich das Projekt erst einmal ruhen lassen.
 
Zuletzt bearbeitet:
snuu hat gesagt.:
Sag mir bitte nicht, Du hast Dich in die Struktur binnen 3 Minuten eingearbeitet und in dieser Zeit auch noch Deinen Beitrag verfasst.
Nö, weiter unten siehst du meine ersten Kommentare
Um Dein Beispiel heran zu ziehen: Die Beziehung zwischen dem Auto und der Kleidung wird mittels der Tabelle PRODUKT_EMPFEHLUNGEN hergestellt.
Ach nee. Ich will ein Auto verkaufen, also habe ich extrem viele Anpassungsmöglichkeiten, die nicht durch PRODUKT_EMPFEHLUNGEN abgedeckt werden.
Wie Du bereits sagtest: Nachdenken!
Q.E.D

Übrigens sage ich auch nicht, dass ein Shop DAS Problem ist. Aber du solltest deine Überheblichkeit einschränken, denn selbst diese kleinen Probleme entwicklen sich schnell zu größeren.
Und wenn du jetzt noch ein wenig nachdenkst (besonders in Hinblick auf Komfort) dann siehst du auch langsam ein paar von den Problemen ankriechen.
 
Zuletzt bearbeitet:
Zurück