Shopdatenbankstruktur

[geru]

Hallo,

da ich gerade einen Shop programmiere, würde mich einmal die Erfahrungen anderer interessieren, was es die Datenbankstruktur angeht.

1. Wie ist denn üblicherweise der Tabellenaufbau eines Shops mit mehreren Haupt- und Unterkategorien gelöst, so dass ein Artikel in mehreren Kategorien erscheint.
z.B.
Artikel: Festplatte
Kategorie: Computer, Hardware, Speicher, ... , Angebote, Neuheiten, ...

Ist dann eine Tabelle mit den Feldern der Kategorien anzulegen und für jeden Artikel einen Eintrag ??

2. Wenn es Artikel gibt in verschiedenen Grössen und Farben und jeweils ein eigener Preis zu berücksichtigen gilt. Wie wird das dann gelöst, wenn der Aufpreis nicht bei jeder Farbe gleich ist?

Ich hoffe es gibt "Standard"-antworten, da es ja die Funktionen bei den meisten Shops gibt.

Beste Grüsse
geru

[Bio]

Sup!

Ich fürchte fast, daß diejenigen, die besonders lange an ihrem Datenbank-Design gearbeitet haben, es nicht verraten wollen.
Da wirst Du schon selbst nachdenken müssen.

Gruesse,

Bio

[Mulder]

Ich fürchte fast, daß diejenigen, die besonders lange an ihrem Datenbank-Design gearbeitet haben, es nicht verraten wollen.
Da wirst Du schon selbst nachdenken müssen.

Ich habe über 50 Tabellen in meinem Shop (www.doccheckshop.de).
Aber trotzdem gebe ich gerne Tips, denn letztlich ist ja doch bloß alles auf dem relationalen Modell aufgebaut.
Und außerdem kann man so ein Design auch nicht "klauen", da es ohne die darauf abgestimmte Applikation (damit meine ich sowohl den Code selbst als auch die Anforderungen des Shop-Betreibers) eh nur instruktiven Wert hat.

Mein SQL bewache ich da schon sorgfältiger. ;-)

[Bio]

Sup!

Ich habe über 50 Tabellen in meinem Shop (www.doccheckshop.de).
Aber trotzdem gebe ich gerne Tips, denn letztlich ist ja doch bloß alles auf dem relationalen Modell aufgebaut.

Wenn es keine objektrelationale oder objektorientierte oder hierarchische Datenbank oder eine Datenbank für Data Warehousing ist, dann vielleicht.

Gruesse,

Bio

[Jan Huss]

Hallo,

die Struktur hängt von Deinem Anliegen ab; bei mir würde sie zum Beispiel so aussehen:

t01categories:
t01prnb, t01mother, t01position, t01name
1, 0, 1, Haupt1
2, 0, 2, Haupt2
3, 1, 1, Haupt1-Unter1
4, 1, 2, Haupt1-Unter2
5, 2, 1, Haupt2-Unter1
6, 0, 3, Haupt3
...

Jede Kategorie hat eine mother. Das ist der Primärschlüssel des Vorgängers. Dazu die Position, welche sagt an welcher Position der Eintrag steht.

t02artikles:
t02prnb, t02mother, t02position, t02data
1, 1, 1, 1. Artikel in Haupt1
2, 4, 1, 1. Artikel in Haupt1-Unter1

Damit solltest Du ganz flexibel sein.

Gruß Jan

[Stephan Huber]

Hallo geru,

Ist dann eine Tabelle mit den Feldern der Kategorien anzulegen und für jeden Artikel einen Eintrag ??

Wenn der Artikel in mehreren Kategorien erscheinen soll, braucht man eine spezielle Tabelle, in der Artikel-ID und Kategorie-ID gespeichert werden. So kann es dann für einen Artikel mehrere Einträge geben.
Meinst Du das?

2. Wenn es Artikel gibt in verschiedenen Grössen und Farben und jeweils ein eigener Preis zu berücksichtigen gilt. Wie wird das dann gelöst, wenn der Aufpreis nicht bei jeder Farbe gleich ist?

Ich habe das mal wie folgt gelöst, aber das kommt wirklich sehr auf die Art von Artikeln an, die verkauft werden, und wie Preise/Aufpreise berechnet werden, wenn Du keine sehr einfache Artikelstruktur hast, gibt es keine "Standard"-Antwort.
Es gibt eine Tabelle "Artikeloptionen", die steht in 1:n Relation zur Artikeltabelle, und für einen bestimmten Artikel stehen dann da zwei Datensätze drin, z.B. "Größe" und "Farbe". Dazu gibt es dann wiederum eine 1:n verknüpfte Detailtabelle, in der dann die einzelnen Farben, und ihr Aufpreis drinstehen.

Artikel    Artikeloptionen        Optionendetails
ID         ID|ArtikelID|Option|   ID|OptionID|Option|Aufpreis
7|Pulli|-> 5 |  7      |Farbe |-> 1 |   5    |gelb  |    5
                              |-> 2 |   5    |rot   |   10

Viele Grüße
Stephan