nicht angemeldet
Hi!
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.
Das versteh ich wiederum nicht ;-)
Was habe ich denn für SQL-Abfragen? Das wären am Anfang, wo alle Kategorien zugeklappt sind sowas:
SELECT titel FROM struktur WHERE Parent_ID = 0
In der Tabelle Struktur sind _maximal_ 100.000 Datensätze und die Tabelle enthält nur 3 Spalten, 2 x SMALLINT und eine CHAR. So ein Zugriff wie oben mit einem Index über PARENT_ID ist IMHO sehr schnell. OK, weiter gehts:
Jemand klickt auf KAtegorie "Lebensmittel", also folgt eien Abfrage wie die:
SELECT ID,titel FROM struktur WHERE Parent_ID = 3
Gilt wieder dasselbe wie oben, so geht das immer weiter, bis ich irgendwann in der untersten Ebene keine Datensätze zurück bekomme -> es gibt also keine Unterkategorien mehr. Also muss ich die Daten aus der Produkte-Tabelle auslesen:
SELECT ID,titel FROM produkte WHERE Kategorie_ID = 5
Ja, die Tabelle ist etwas größer, aber das lässt sich IMHO nicht anders/besser lösen. Hier lege ich halt ebenfalls eine Index über Kategorie_ID.
Danach klickt man auf eines der Produkte, also komtm so eien Abfrage:
SELECT * FROM produkte WHERE ID = 123
Gut, also hier noch ein Index über ID. Beim Bearbeiten der Struktur habe ich in etwa die selben Abfragen, dazu kommen ggfs. INSERT und UPDATE Abfragen, aber die sind auch sehr einfach, es wird immer nur ein neuer DS hinzugefügt oder aktuelisiert, ich muss keine Beziehungs-Tabellen pflegen...
Udn auch das mit dem Cachen als Array werde ich wohl lassen, denn wenn ich es mir recht überlege ist das so schon schnell genug, e könnte dagegen sein, wen PHP dann jedesmal einen mehrere MB großen Array von der Platte liest, dass das ganze langsamer wird, vor allem bleibt das problem mit den Produkten, sollen die da rein oder nicht, wenn ja dann wird der Array wirklich sehr groß, wenn nein spare ich mir nur die Abfragen auf die Struktur-Tabelle, die IMHO doch schnell genug sein sollten.
btw.: Würdet Ihr eine andere Indizierung er Tabellen vornehmen? Ich würde also sowas machen:
In beiden Tabellen ein primary-key auf ID und jeweils ein einfacher Index auf die parent_id bzw. kategorie_id spalte. Oder sollte ich noch einen über titel legen, oder vielleicht einen über mehrere Spalten (titel und ID)?
Aber mal ein ganz anderes Problem, wie speicher ich am besten den Zustand des Baums, der auf der Internetseite angezeigt wird, halt welche Bereiche auf- und zugeklappt sind? Ich würde es glaueb ich als Array in der Session speichern, d.h. ich schreibe Änderungen am Baum immer in die Session, d.h. wenn z.B. Lebensmittel aufgeklappt wird, dann weise ich dem Schlüssel "Lebensmittel" im Struktur-Array einen Array mit den Unterkategorien hier wiederum alle als Schlüssel der Elemente zu, aber wo speichern ich dann die IDs(die ich ja brauche um der DB mitzuteilen welche Kategorie ausgelesen werden soll)?
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.
Also sowas:
Lebensmittel
Molkereiprodukte
Milchprodukte
Tetra-Pack
- 1 Liter Vollmilch
- 0,5 Liter Vollmilch
Getränke
Spirituosen
- Johnny
- Jack
- Jim
...
Die Milch hängt in der 4. Ebene, die Whiskey's in der 3. Das Beispiel mag nicht so toll sein, aber ich denke Du verstehst was ich meine.
Bei Deiner Lösung hast Du das problem, nicht zu wissen, in welcher Tabelle sich die Kategorie befindet, dafür brauchst Du dann eien Zuordnungs-Tabelle.
Mag sein dass Deine Datenstruktur zu Ausgabe des Baums ein wenig prformanter ist, aber beim Auslesen der entsprechenden produkte ine ienr Kategorie sicherlich nicht, außerdem ist mein version auf keine Ebenen-Zahl beschränkt. Außerdem ist bei einer Solch kleinen Tabele(im Schnitt sicher nur 1000-10.000 Datensätze in der Struktur-Tabelle) die Performance sicher nicht mehr das Problem.
Tabellen, die Relationen halten, um "n:m"-Beziehungen abzubilden? - Warum braucht man denn die im genanten Beispiel?
s.o.
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.
ich nicht, das sind IMHO keine schönen Workarounds.
Ansonsten kommt der von Dir genannte Fehler doch gerade dann tendenziell hoch, wenn man eben nicht alles so einfach wie moeglich abzubilden sucht.
Findest Du Deine Version einfacher? Ich nicht. Sie ist sicherlich kaum schneller nur unflexibler.
Hoffe, dass ich Euch nicht nerve mit meinen Nachfragen, aber vielleicht uebersteigt das Beispiel mein Vorstellungsvermoegen. ;-)
Das kann ich mir bei einem "SQL-Experten" wie Dir nicht wirklich vorstellen ;-)
Grüße
Andreas