verschachteltes Menue

[Mann nannte in H.J.S.]

hallo zusammen,
bin noch neu hier und in dem thema, also habt Erbamen.

Habe jetzt schon einiges in PHP und MySQL durch und dachte mir nun, programmier doch mal nen O-Shop.

Aber da steht man jetzt bei ner klitzekleinen Aufgabe und findet die Lösung nicht.

Mein Menue(bzw meine Datenbank) ist folgendermassen Aufgebaut:

warengruppe
   produktgruppe
      produktuntergruppe
         produkte

In der DB referenziert produktgruppe auf warengruppe, produktuntergruppe auf produktgruppe, produkte auf produktuntergruppe(bisher).
Wie sieht es aus, wenn ich für ein Produkt keine Produktuntergruppe habe?
Z.B. sind in der produktgruppe nur 2 Artikel, da lohnt sich keine Untergruppe.
Die produkte referenzieren zur Zeit auf die Produktuntergruppe. Muss ich, um das Problem zu lösen, jedem produkt auch die Produktgruppe zuweisen?

Hoffe Ihr versteht annähernd mein Problem

Gruß
Homer J. Simpson

[Cheatah]

Hi,

In der DB referenziert produktgruppe auf warengruppe, produktuntergruppe auf produktgruppe, produkte auf produktuntergruppe(bisher).

was unterscheidet diese, wenn Du die Bezeichnung und den Level der Schachtelung auslässt?

Cheatah

[Mann nannte in H.J.S.]

was unterscheidet diese, wenn Du die Bezeichnung und den Level der Schachtelung auslässt?

Wenn ich Dich richtig verstehe(was ich hier wohl verneinen muss), nichts, weil es sind alles Artikel.

Verstehe nicht so ganz worauf Du hinnaus willst? (tut mir leid, aber ich weiss wirklich nicht was Du meinst)

Homer J. Simpson

[Cheatah]

Hi,

»» was unterscheidet diese, wenn Du die Bezeichnung und den Level der Schachtelung auslässt?
Wenn ich Dich richtig verstehe(was ich hier wohl verneinen muss), nichts, weil es sind alles Artikel.

Du verstehst mich richtig. Du hast gleichwertige Einträge im Menü, die sich untereinander referenzieren, und Du hast Artikel, die Einträge in der Navigation referenzieren. Ob sich dadurch im Menü 3, 4 oder 11 Ebenen ergeben, ist völlig uninteressant - Produkte können auch schon im obersten Menüpunkt untergebracht sein.

Cheatah

[Mann nannte in H.J.S.]

Du verstehst mich richtig. Du hast gleichwertige Einträge im Menü, die sich untereinander referenzieren, und Du hast Artikel, die Einträge in der Navigation referenzieren. Ob sich dadurch im Menü 3, 4 oder 11 Ebenen ergeben, ist völlig uninteressant - Produkte können auch schon im obersten Menüpunkt untergebracht sein.

Hi, erstmal dankeschön.
Mit diesem Prinzip müsste ich dann aber auch für jede Produktgruppe eine eigene Abfrage machen, oder sehe ich das falsch?
Hatte es mir so vorgestellt, das ich mehrere Abfrage in while-schleifen verschachtel, und so dann das Menue entstehen lassen.

Das wäre doch dann so nicht mehr möglich, da ja ein Produkt, welches keiner Produktuntergruppe angehört, auch nicht referenziert werden kann.

Vielen Dank für Eure Mühe
Homes J. Simpson

[Cheatah]

Hi,

Mit diesem Prinzip müsste ich dann aber auch für jede Produktgruppe eine eigene Abfrage machen, oder sehe ich das falsch?

das kommt auf Dein grundsätzliches Konzept an. Es ist ebenso gut denkbar, dass Du die Navigationsstruktur auf irgend eine Weise im Speicher hältst, oder dass Du z.B. Menü und Produkte in der selben SQL-Abfrage erhältst. Jedes Verfahren hat Vor- und Nachteile, die gegeneinander abgewogen werden müssen.

Hatte es mir so vorgestellt, das ich mehrere Abfrage in while-schleifen verschachtel, und so dann das Menue entstehen lassen.

Das ist vermutlich der ungünstigste Weg. Der Roundtrip ist mit das Teuerste an einer SQL-Abfrage.

Das wäre doch dann so nicht mehr möglich, da ja ein Produkt, welches keiner Produktuntergruppe angehört, auch nicht referenziert werden kann.

Es gibt keine Produktuntergruppe. Es gibt einen Menüpunkt. Wo sich dieser befindet, ist unerheblich.

Cheatah

[suit]

Ob sich dadurch im Menü 3, 4 oder 11 Ebenen ergeben, ist völlig uninteressant

Sag' das mal irgendwelchen theoretischen Physikern, die sich über die Anzahl der möglicherweise vorhanden Raumdimensionen streiten, damit irgend eine Theorie "funktioniert". Ob das jetzt 3 (klassisch), 4 (Kaluza-Klein-Theorie) oder 11 (String-Theorie) spielt da eine große Rolle :)

[Cheatah]

Hi,

Sag' das mal irgendwelchen theoretischen Physikern, die sich über die Anzahl der möglicherweise vorhanden Raumdimensionen streiten, damit irgend eine Theorie "funktioniert". Ob das jetzt 3 (klassisch), 4 (Kaluza-Klein-Theorie) oder 11 (String-Theorie) spielt da eine große Rolle :)

nein, das ist unerheblich. Wir alle wissen doch, dass es entweder 42 (Adams) oder 47 (Braga/Taylor) Raumdimensionen gibt. Und die Navigation findet über 3 (klassisch) oder 2 (Khan Noonian Singh) Dimensionen statt, womit wir hier also auch kein Problem haben. Und wenn mal eine vierte Dimension hinzu kommt, dann landet Spock in der Eishöhle[1], aus der sich schon Luke Skywalker vom Yeti befreit hat. Alles in allem bleibt's also in der Familie.

Cheatah ;-)

[1] Wer den neuesten Star Trek noch nicht im Kino gesehen hat, sollte diesen Mangel sofort abstellen!

[suit]

[1] Wer den neuesten Star Trek noch nicht im Kino gesehen hat, sollte diesen Mangel sofort abstellen!

Ich war letzte Woche leider krank, ich werde das dieses Wochenede sofort nachholen :)

[Ilja]

moin,

Die produkte referenzieren zur Zeit auf die Produktuntergruppe. Muss ich, um das Problem zu lösen, jedem produkt auch die Produktgruppe zuweisen?

ich nehme mal an, du hast 4 tabellen und eben eine tabelle produkte (mein vorschlag wäre, für die tabellenbezeichner immer den singular zu benutzen) mit einem fremdschlüssell auf die tabelle produktuntergruppe. je nachdem wie du diesen fremdschlüsselspalte deklariert hast, kannst du dort einfach NULL eintragen. dabei ist zu beachten, dass NULL <> 0 und auch NULL <> '' ist, sondern ein spezifischer "wert" extra für datenbanken.

was genau NULL bedeutet, ist ein wenig strittig. meine aussage dazu ist, NULL steht für einen undefinierten wert, über den ich keine und zwar gar keine aussage machen kann. andere wiederum sehen in den wert auch eine fachliche bedeutung, wie zum beispiel "nicht vorhanden", davon würde ich persönlich aber immer abraten.

die andere frage ist, ob es wirklich von vorteil ist, einem produkt keine produktuntergruppe zuzuordnen. das hat später auswirungen auf deine abfragen und muss mit beachtet werden. willst du zum beispiel alle deine produkte mit ihren entsprechenden produktuntergruppen anzeigen, kann es dir passieren, dass die produkte ohne untergruppe eben nicht mehr angezeigt werden, wenn du das nicht entsprechend berücksichtigst. hier wäre mein vorschlag, gib jedem produkt eine produktuntergruppe, jeder produktuntergruppe eine produktgruppe und jeder produktgruppe eine warengruppe, das ist meiner ansicht nach sauberer.

Ilja

[EKKi]

Mahlzeit Mann nannte in H.J.S.,

warengruppe
   produktgruppe
      produktuntergruppe
         produkte

Eventuell wäre es sinnvoller, die Tabellen "warengruppe", "produktgruppe" und "produktuntergruppe" zusammenzufassen ... und zwar dergestalt, dass jedes "Kind" einfach eine entsprechende "Eltern"-Gruppe referenzieren kann. Die Baumstruktur und die Hiearchieebene jeder einzelnen Gruppe ergibt sich dann automatisch aus den entsprechenden Referenzen (wobei man natürlich jeder Gruppe noch einen "Gruppentyp" o.ä. verpassen könnte).

Dann hättest Du es nämlich in Deiner Tabelle "produkte" einfach - jedes Produkt referenziert auf eine Gruppe ... welcher Art diese Gruppe ist und wo in der Hierarchie sie angesiedelt ist, spielt dann keine Rolle. Alternativ wäre auch zu überlegen, ob Du nicht lieber eine Zuordnungstabelle "produkt2gruppe" o.ä. anlegen willst, so dass Du jedes Produkt in mehrere Gruppen einsortieren kannst (wenn das erforderlich ist). In dem Fall würde die direkt Referenzierung von "produkt" nach "gruppe" wegfallen, die Tabelle "produkt2gruppe" müsste dann auf beide Tabellen referenzieren (sinnvollerweise mit einem UNIQUE-Constraint auf die beiden Foreign-Keys).

MfG,
EKKi

[Ilja]

yo,

Eventuell wäre es sinnvoller, die Tabellen "warengruppe", "produktgruppe" und "produktuntergruppe" zusammenzufassen ... und zwar dergestalt, dass jedes "Kind" einfach eine entsprechende "Eltern"-Gruppe referenzieren kann. Die Baumstruktur und die Hiearchieebene jeder einzelnen Gruppe ergibt sich dann automatisch aus den entsprechenden Referenzen (wobei man natürlich jeder Gruppe noch einen "Gruppentyp" o.ä. verpassen könnte).

würde ich in diesem falle von abraten. zum einen sind hierachien in rdbms nicht immer unproblematisch. zum anderen sind wohl die attribute der jeweiligen entitäten unterschiedlich.

Ilja

[EKKi]

Mahlzeit Ilja,

zum anderen sind wohl die attribute der jeweiligen entitäten unterschiedlich.

Deswegen schrieb ich ja auch "eventuell". Es kommt halt darauf an, was genau diese Tabellen enthalten - und das hat H.J.S. ja bisher nicht preisgegeben.

Ich wollte lediglich ein paar Denkanstöße geben ... denn das aktuelle Datenbankdesign ist IMHO alles andere als sinnvoll.

MfG,
EKKi

[Ilja]

yo,

Ich wollte lediglich ein paar Denkanstöße geben ... denn das aktuelle Datenbankdesign ist IMHO alles andere als sinnvoll.

so wie auch der denkanstoss, ich kann den sinn darin nicht wirklich erkennen.

Ilja

[EKKi]

Mahlzeit Ilja,

»» Ich wollte lediglich ein paar Denkanstöße geben ... denn das aktuelle Datenbankdesign ist IMHO alles andere als sinnvoll.

so wie auch der denkanstoss, ich kann den sinn darin nicht wirklich erkennen.

Heute in Pöbellaune?

MfG,
EKKi

[Ilja]

yo,

Heute in Pöbellaune?

ganz im gegenteil, bin bestens gelaunt, zumal heute auch freitag ist. aber ich kann immer noch keine sinnhaftigkeit in dem denkanstoss erkennen, die es lohnen würdem dem weiter nachzugehen.

Ilja

[EKKi]

Mahlzeit Ilja,

aber ich kann immer noch keine sinnhaftigkeit in dem denkanstoss erkennen, die es lohnen würdem dem weiter nachzugehen.

Ich schrieb "Eventuell wäre es sinnvoller" ... weil ich nicht wusste und weiß, was für Eigenschaften die verschiedenen Strukturebenen haben.

Wenn man jedoch einzelne Produkte in verschiedene Ebenen "einhängen" will, dann wäre es IMHO äußerst ungünstig, diese Ebenen in verschiedenen Tabellen zu speichern und dann in der Produkt-Tabelle Foreign-Keys zu verschiedenen Tabellen speichern zu müssen oder ähnliche unsaubere Aktionen.

Wie sähe denn Dein Vorschlag aus für eine saubere, (offensichtlich) hierarchische gegliederte Struktur, die auf jeder Ebene "Kindobjekte" des gleichen Typs enthalten können soll?

MfG,
EKKi