nicht angemeldet
Hallo, Klaus,
Wenn Du den Sachverhalt mit 5 Tabellen besser abbildest, weil es eben eine fuenfstufige Datenstruktur ist, dann solltest Du das auch machen.
Irgendwie sehe ich hier keinen Vorteil gegenüber einer Strukturtabelle.
Der Schaden, der entsteht wenn mithilfe der "umgebenden Programmlogik" Abfrageergebnisse erzeugt werden, weil SQL nicht mehr reicht, ist u.a. ein langsamer Datenzugriff.
Eigentlich sehe ich eher Nachteile. Wie willst Du es mit fünf Strukturtabellen schaffen, daß, wie im Ausgangsbeispiel angeführt, Artikel in jeder beliebigen Ebene eingehängt werden können, ohne Probleme mit den Beziehungen zu bekommen?
Sorry, das habe ich bis jetzt nicht verstanden. - Es sollen Datensaetze "logisch" in mehreren Ebenen gehalten werden? - Bitte nenne doch mal ein Beispiel.
Imho würdest Du fünf weitere Tabellen benötigen, um die Beziehungen der Artikel mit den jeweiligen 'Verzeichnistabellen' zu definieren.
Tabellen, die Relationen halten, um "n:m"-Beziehungen abzubilden? - Warum braucht man denn die im genanten Beispiel?
Was wiederum zur Folge hat, daß man, wenn es denn so gefordert sein sollte, sich überlegen muß wie man es verhindert, daß ein Artikel plötzlich in mehreren 'Verzeichnissen' in unterschiedlichen Ebenen auftaucht.
Wenn Du z.B. meinst, dass 'Artikel' logisch immer in die fuenfte Ebene gehoeren und es gibt keine dritte oder vierte Ebene, so kann man diese dennoch ueber "Dummy"-Datensaetze verzeigern. Das empfaende ich als durchaus normal. - Ansonsten kommt der von Dir genannte Fehler doch gerade dann tendenziell hoch, wenn man eben nicht alles so einfach wie moeglich abzubilden sucht.
Und wenn die Datenbank nicht über eine Funktionalität verfügt, die Rekusrionen aufzulösen, dann muß halt externe Programmlogik her. Aber das ist in Deinem Ansatz, soweit ich ihn richtig verstanden habe, auch notwendig.
Hoffe, dass ich Euch nicht nerve mit meinen Nachfragen, aber vielleicht uebersteigt das Beispiel mein Vorstellungsvermoegen. ;-)
Gruss,
Lude