Warengruppenstruktur - in XML oder RDBMS speichern?

[Andreas Korthaus]

Hallo!

Ich will eine maximal 5-Stufige Warengruppenstruktur speichern. Das sieht dann z.B. so aus:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
      1 Liter Frische Vollmilch
      1 Liter fettarme Milch
      0,5 Liter frische Vollmilch
    Quarkprodukte
  Backwaren

Nur mal so als Beispiel. Wie gesagt, maximal 5 Ebenen, aber nicht überall 5 Ebenen, in der einen Gruppe sind es 3 in der nächsten 5... kommt halt auf die Komplexität der Warengruppe an. Jetzt überlege ich, wie ich das speichere. Ich greife hierauf mit PHP zu, das heißt ich muss zum einen ein Interface schaffen um Daten einzugeben und zu bearbeiten, und auf der anderen Seite die Warengruppenstruktur in einem Baum (wie im Windows-Explorer) auf einer Homepage mit HTML oder Javascript ausgeben.

Jetzt überlege ich wie ich dies am besten implementiere. Das Problem,  die Warengruppenstruktur kann unterschiedlich groß sein, das ist halt nicht festgelegt. Das können 100 Produkte sein, aber auch 100.000. Gut, das ist vielleicht eher unwahrscheinlich, aber 10.000 ist durchaus nicht selten. Am Ende soll es so sein dass man sich durch diesen Baum mit der Warengruppenstruktur klickt und auf der untersten Ebene dann die Produkte in dieser Warengruppe auswählen kann. Nur wenn ich jetzt Struktur und Produkte getrennt speichere, habe ich bei der Erstellung des Baums das Problem dass ich mir die Informationen aus den beiden Datenquellen zusammensuchen muss. Unter Performance - GEsichtspunkten sieht es eher schlecht aus für XML, denn dann muss man immer die komplette Datei parsen(wegen PHP), trotzdem ist XML ja eigentlich das geeignetere Format um so eine Struktur abzubilden.

Zu den Produkten sollen noch einige Informationen wie Titel, Beschreibung, Spezifikation, Bild(Link).

<?xml version="1.0" encoding="ISO-8859-1"?>
<Warengruppen>
  <Lebensmittel>
    <Getränke>
    </Getränke>
      <Molkereiprodukte>
        <Milchprodukte>
          <Artikel title="1 Liter Frische Vollmilch">
            <Beschreibung>1 Liter frische Vollmilch vom Biobauren im Tetra-Pack... </Beschreibung>
            <Spezifikation>DIN ISO 12345; Kuhmilchverordnung $123</Spezifikation>
            <bild>schoene_milch_12345.jpg</bild>
          </Artikel>
          <Artikel tilte="1 Liter fettarme Milch">
            <Beschreibung>1 Liter fettarme Milch vom Biobauren im Tetra-Pack... </Beschreibung>
            <Spezifikation>DIN ISO 12346; Kuhmilchverordnung $123</Spezifikation>
            <bild>schoene_milch_12346.jpg</bild>
          </Artikel>
          <Artikel title="0,5 Liter frische Vollmilch">
            <Beschreibung>0,5 Liter frische Vollmilch vom Biobauren im Tetra-Pack... </Beschreibung>
            <Spezifikation>DIN ISO 12347; Kuhmilchverordnung $123</Spezifikation>
            <bild>schoene_milch_12347.jpg</bild>
          </Artikel>
        </Milchprodukte>
        <Quarkprodukte>
        </Quarkprodukte>
      </Molkereiprodukte>
    <Backwaren>
    </Backwaren>
  </Lebensmittel>
</Warengruppen>

Oder würdet Ihr so eine XML-Datei anders aufbauen? So wie jetzt würden die Produkte den mit Abstand größten Teil in Anspruch nehmen, vielleicht sollte ich tatsächlich nur die Struktur in XML speichern, und alles was ich jetzt in den "Artikel"-Tags habe in eine DB-Tabelle verlagern. Der Performance zuliebe würde ich denke ich noch in PHP mit Hilfe von var_export als PHP-Array speichern, ich denke das geht erheblich schneller bei Zugriffen als jedesmal den XML-Parser anzuwerfen. Oder würdet Ihr eher serialize verwenden?

Viele Grüße
Andreas

[Lude]

Hi,

Ich will eine maximal 5-Stufige Warengruppenstruktur speichern. Das sieht dann z.B. so aus:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
      1 Liter Frische Vollmilch
      1 Liter fettarme Milch
      0,5 Liter frische Vollmilch
    Quarkprodukte
  Backwaren

Das können 100 Produkte sein, aber auch 100.000.

wenn das Schema bekannt ist und wenn einige Tausend "Datensaetze" gespeichert werden muessen, so scheint m.E. eine "RDB(M)S" eindeutig praeferabel.

Gruss,
Lude

[Andreas Korthaus]

Hi Lude!

wenn das Schema bekannt ist und wenn einige Tausend "Datensaetze" gespeichert werden muessen, so scheint m.E. eine "RDB(M)S" eindeutig praeferabel.

Die Datensätze, also die Artikel, würde ich ja im Augenblick auch in einer DB speichern, nur die Struktur, die nicht feststeht, vom Anwender ggfs. veränderbar sein soll, würde ich glaube ich in XML speichern. Die Performance der Speicherung speilt ja keine Rolle mehr wenn ich diese Struktur eh als PHP-Array "cache". Und diese Struktur wird sicherlich auch nicht so groß. Vielleicht insgesamt 100-1000 Gruppen (inkl. Untergruppen). Oder ist die Trennung der Struktur von den Produktdaten nicht so toll? In der Datenbank würde man das ja sowieso auch machen. Nur wenn ich das so mache, dann brauche ich auch eindeutige IDs für alle Gruppen und Untergruppen, prinzipiell ist das ganze ja auch mit diesem Forum hier zu vergleichen, naja. Aber die Sache mit den IDs gefällt mir nicht wirklich, aber ich brauche ja irgendeine Art von Schlüssel um die Produkte in der Datenbank eine Kategorie zuordnen zu können, das ist halt der Preis des getrennten "Designs". Hm, vielleicht speicher ich die Struktur doch lieber in einer Tabelle, halt immer mit ID und Parent_ID, wie wie in Henryks PHP/MySQL Forums-Artikel? Denn wenn ich sowieso einen PHP-Array abspeicher bringt mir die XML-Struktur auch nicht merh so viel, hm...

Grüße
Andreas

[Lude]

Hi,

Die Datensätze, also die Artikel, würde ich ja im Augenblick auch in einer DB speichern, nur die Struktur, die nicht feststeht, vom Anwender ggfs. veränderbar sein soll, würde ich glaube ich in XML speichern.

nach dem, was ich gesehen und verstanden habe, steht die "Struktur" fest.

Oder ist die Trennung der Struktur von den Produktdaten nicht so toll?

Eigentlich nicht (wenn ich Dich halbwegs verstanden habe).   ;-)

[Rest, den ich nicht wirklich verstanden habe]

Ich kenne da zumindest einen hier, der die _richtigen_ Nachfragen stellen wird.   ;-)

Gruss,
Lude

[Andreas Korthaus]

Hi!

Oder ist die Trennung der Struktur von den Produktdaten nicht so toll?

Eigentlich nicht (wenn ich Dich halbwegs verstanden habe).   ;-)

was denn jetzt, ist es toll oder nicht so toll? ;-)

[Rest, den ich nicht wirklich verstanden habe]

Was hast Du nicht verstanden? Dass ich eindeutige IDs für jede einzelne Gruppe brauche? Wie soll ich sonst die Artikel aus der Gruppe "Milchprodukte" wieder dieser Kategorie zuordnen wenn ich die Artikel alle in der DB speichere? Ich muss dann sowas wie "Kategorie_id" als Spalte haben, und das ist dann die ID eben von z.B. "Milchprodukte". Nur diese IDs brauche ich ja nicht wirklich fürt die XML-Struktur an sich, halt nur für die Zuordnung der Artikel.
Und so ein Baum wie die Warengruppenstruktur ähnelt halt sehr stark dem Baum der Threads auf der Startseite dieses Forums, oder?

Viele Grüße
Andreas

[Lude]

Hi,

[Rest, den ich nicht wirklich verstanden habe]
Was hast Du nicht verstanden? Dass ich eindeutige IDs für jede einzelne Gruppe brauche? Wie soll ich sonst die Artikel aus der Gruppe "Milchprodukte" wieder dieser Kategorie zuordnen wenn ich die Artikel alle in der DB speichere? Ich muss dann sowas wie "Kategorie_id" als Spalte haben, und das ist dann die ID eben von z.B. "Milchprodukte". Nur diese IDs brauche ich ja nicht wirklich fürt die XML-Struktur an sich, halt nur für die Zuordnung der Artikel.

ein XML-Dokument ist mit einer DB in einem RDB(M)S vergleichbar. - Habe ich richtig verstanden, dass die Nutzer Aenderungen am Schema machen duerfen??

Und so ein Baum wie die Warengruppenstruktur ähnelt halt sehr stark dem Baum der Threads auf der Startseite dieses Forums, oder?

Hast Du vielleicht vor das von Dir beschriebene Schema in einer Datentabelle abzubilden?? - Andernfalls sehe ich (bisher) keine Aehnlichkeit zum Forum mit seiner "in der Tabelle 'Beitraege'" gehaltenen Verweise auf "Vorgaenger".

Gruss,
Lude

PS: @Klaus Mock: Verstehe bisher immer nur Bahnhof.   ;-)

[Andreas Korthaus]

Hi!

ein XML-Dokument ist mit einer DB in einem RDB(M)S vergleichbar.

sicher, ist schon vergleichbar, trotzdem ist en XML-Dokument deutlich besser für hierarchische Strukturen geeignet, da man das in Relationalen Datenstrukturen mit Parent_ID & Co. umständlich nachbilden muss. Aber ein Teil der Daten in der DB und der ander in XML gefällt mir auch nicht so gut.

• Habe ich richtig verstanden, dass die Nutzer Aenderungen am Schema machen duerfen??

Ja. Ich würde die komplette Struktur in einer Tabelle abbilden, und bei jedem Gruppennamen eine ID und die Parent_ID speichern, so dass ich hinterher die Knoten ermitteln aknn und eine Baumstruktur daraus bauen kann. Der Benutzer kann dann halt die Struktur ändern, entsprechend werden dann halt die Datensätze geändert.

In etwas sieht das so aus:

Struktur:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
    Quarkprodukte
  Backwaren

Tabelle "struktur":

ID | Parent_ID |Titel
---+-----------+------
1  | 0         | Lebensmittel
2  | 1         | Getränke
3  | 1         | Molkereiprodukte
4  | 3         | Milchprodukte
5  | 3         | Quarkprodukte
6  | 1         | Backwaren
...

Produte:
      1 Liter Frische Vollmilch
      1 Liter fettarme Milch
      0,5 Liter frische Vollmilch

Tabelle "produkte":

ID | Struktur_ID |Titel                        | Beschreibung | Bild
---+-------------+-----------------------------+--------------+------------------------------
1  | 4           | 1 Liter Frische Vollmilch   | blabla1...   | schoene_milch_12345.jpg
2  | 4           | 1 Liter fettarme Milch      | blabla2...   | schoene_milch_12346.jpg
3  | 4           | 0,5 Liter frische Vollmilch | blabla3...   | schoene_milch_12347.jpg
...

Das erstellen der Struktur, also das "bauen" des Baums mache ich dann mit einer rekursiven Funktion, sowas wie hier: http://aktuell.de.selfhtml.org/artikel/phpasp/php-forum/index.htm#a3

Hast Du vielleicht vor das von Dir beschriebene Schema in einer Datentabelle abzubilden??

Ja, s.o.

PS: @Klaus Mock: Verstehe bisher immer nur Bahnhof.   ;-)

Was verstehst Du nicht?

Viele Grüße
Andreas

[Lude]

Hi,

ein XML-Dokument ist mit einer DB in einem RDB(M)S vergleichbar.
sicher, ist schon vergleichbar,

klar.   ;-)

trotzdem ist en XML-Dokument deutlich besser für hierarchische Strukturen geeignet, da man das in Relationalen Datenstrukturen mit Parent_ID & Co. umständlich nachbilden muss.

Ich denke, dass man jedes XML-Schema in einem geeigneten RDBMS nachbilden koennte. Wenn sich das Schema aber fortlaufend aendert, dann muessen "radikale" Loesungen her.   ;-)

Aber ein Teil der Daten in der DB und der ander in XML gefällt mir auch nicht so gut.

Ja.

[Erlaeuterungen]

Das erstellen der Struktur, also das "bauen" des Baums mache ich dann mit einer rekursiven Funktion, sowas wie hier: http://aktuell.de.selfhtml.org/artikel/phpasp/php-forum/index.htm#a3

Hast Du vielleicht vor das von Dir beschriebene Schema in einer Datentabelle abzubilden??
Ja, s.o.

PS: @Klaus Mock: Verstehe bisher immer nur Bahnhof.   ;-)
Was verstehst Du nicht?

Nun alles verstanden. - Warum speicherst Du die Dokumente nicht einfach en bloc, bzw. "en BLOB"? - Oder im Filesystem? - Eine "Struktur" ist ja kaum noch erkennbar. - Wenn es wenigstens eine Obergrenze fuer die Verschachtelungen geben wuerde, dann koenntest Du vielleicht mit "Level-Tabellen" (also exakt 5 Tabellen bei einer max. Verschachtelungstiefe von 5) kommen, wegen der ref. Integritaet z.B.

Gruss,
Lude

[Andreas Korthaus]

Hi!

Ich denke, dass man jedes XML-Schema in einem geeigneten RDBMS nachbilden koennte.

Hm, meiner Meinung nach sind das zwei doch verschiedene Konzepte mit unterschiedlichen Stärken  und Schwächen. Für die Speicherung größerer Datenmengen ist XML IMHO weniger gut geeignet, dafür um so mehr für hierarchische Strukturen.

Wenn sich das Schema aber fortlaufend aendert, dann muessen "radikale" Loesungen her.   ;-)

Wieso Radikal? Findest Du meine Idee der DB-Struktur radikal?

Nun alles verstanden. - Warum speicherst Du die Dokumente nicht einfach en bloc, bzw. "en BLOB"? - Oder im Filesystem?

Welche Dokumente meinst Du? Ich speicher alles im Filesystem - wobei - ein PHP-Dämon der die Struktur im Speicher hält, keine üble Idee ;-)

• Eine "Struktur" ist ja kaum noch erkennbar. - Wenn es wenigstens eine Obergrenze fuer die Verschachtelungen geben wuerde,

Die gibt es, mit 5, wobei die Begrenzung bei meiner Struktur oben gar nicht mehr notwendig ist.

dann koenntest Du vielleicht mit "Level-Tabellen" (also exakt 5 Tabellen bei einer max. Verschachtelungstiefe von 5) kommen, wegen der ref. Integritaet z.B.

Kann man referenzielle Integrität eigentlich nicht auch in einer Tabelle verwenden? Halt in der Tabelle "struktur" wie ich sie mir im Posting vorher überlegt habe?

Grüße
Andreas

[Lude]

Hi,

Ich denke, dass man jedes XML-Schema in einem geeigneten RDBMS nachbilden koennte.
Hm, meiner Meinung nach sind das zwei doch verschiedene Konzepte mit unterschiedlichen Stärken  und Schwächen. Für die Speicherung größerer Datenmengen ist XML IMHO weniger gut geeignet, dafür um so mehr für hierarchische Strukturen.

<exkurs>
Was sind Daten? Daten (lat.; die Gegebenen) bilden einen relevanten Sachverhalt der Realitaet ab. Ausserdem kommen Daten immer in der Struktur eines XML-Dokuments oder einer DB in einem RDBMS. Also eine Tabellenmenge, die irgendwie verzeigert ist. Mit einem Wurzel-Element.
<sub_e>
(Es gibt eben Daten, (Geschaefts)logik (Regelmenge kommt in derselben Struktur wie die Daten) und Ausgabe (Ausgabemenge ebenfalls in derselben Struktur wie die Daten))
</sub_e>
</exkurs>

Nun alles verstanden. - Warum speicherst Du die Dokumente nicht einfach en bloc, bzw. "en BLOB"? - Oder im Filesystem?
Welche Dokumente meinst Du? Ich speicher alles im Filesystem - wobei - ein PHP-Dämon der die Struktur im Speicher hält, keine üble Idee ;-)

Beim Forum haben wir es mit gut strukturierten Daten zu tun - im Gegensatz zu den Daten Deiner Anforderungslage. btw - Ist es richtig, dass Beitraege jetzt zeitversetzt (5 Sekunden?) im Forum erscheinen? Oder war das immer schon so?

dann koenntest Du vielleicht mit "Level-Tabellen" (also exakt 5 Tabellen bei einer max. Verschachtelungstiefe von 5) kommen, wegen der ref. Integritaet z.B.
Kann man referenzielle Integrität eigentlich nicht auch in einer Tabelle verwenden? Halt in der Tabelle "struktur" wie ich sie mir im Posting vorher überlegt habe?

Wenn Du den Sachverhalt mit 5 Tabellen besser abbildest, weil es eben eine fuenfstufige Datenstruktur ist, dann solltest Du das auch machen. - Belohnt wirst Du durch vom RDB(M)S sichergestellte referenzielle Integritaet (andere Integritaeten kennt das System uebrigens auch, was hilfreich ist). Ausserdem durch wesentliche bessere Performance, vgl. mit "selbstverzeigerten" Datensaetzen in einer Tabelle. Alles Dank der bekannten Verschachtelungstiefe. Prima. - Einem XML-Dokument koenntest Du, wenn ich die Anforderungslage hinreichend nachvollziehen konnte, niemals ein geeignetes Schema entwickeln. (Oder lerne ich jetzt etwas ueber XML   ;-)

Viele Gruesse,
Lude

[Klaus Mock]

Hallo,

Kann man referenzielle Integrität eigentlich nicht auch in einer Tabelle verwenden?

Wenn Dein DBMS referenzielle Integritäten definieren kann, kann man in der Regel auch Beziehungen einer Teabelle auf sich selbst definieren.

Wenn Du den Sachverhalt mit 5 Tabellen besser abbildest, weil es eben eine fuenfstufige Datenstruktur ist, dann solltest Du das auch machen. - Belohnt wirst Du durch vom RDB(M)S sichergestellte referenzielle Integritaet (andere Integritaeten kennt das System uebrigens auch, was hilfreich ist). Ausserdem durch wesentliche bessere Performance, vgl. mit "selbstverzeigerten" Datensaetzen in einer Tabelle.

Irgendwie sehe ich hier keinen Vorteil gegenüber einer Strukturtabelle. 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? Imho würdest Du fünf weitere Tabellen benötigen, um die Beziehungen der Artikel mit den jeweiligen 'Verzeichnistabellen' zu definieren. 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.

Ich halte den Ansatz von Andreas in [pref:t=53383&m=295932] für durchaus geeignet, um die geforderten Gegebenheiten in einer Datenbank sauber abzubilden. 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.

Grüße
  Klaus

[Lude]

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

[Andreas Korthaus]

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

[Lude]

Hi,

danke fuer Eure Geduld! Ich hab's jetzt wohl so halbwegs kapiert. - Bin ja kein "SQL-Experte".   ;-)
(Allerdings verstaerkt sich bei mir der Eindruck, dass Du "nur" Datensaetze speichern willst, in diesem Fall 'Artikel', die kategorisiert werden sollen. - Das habe ich auch schon gemacht - bei mir haben bisher aber immer insgesamt drei "starre" Kategorien und Unterkategorien gereicht. - Kategoriesierung mithilfe von vier Kategorien und dann noch "dynamisch"? Das war fuer mich einfach zuviel.)

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 ;-)

[Beispiele]

dann mach mal eine Zeitmessung und Du wirst staunen. Insbesonders das "rekursive Element", realisiert mithilfe von "umgebender Programmlogik", "haut rein".

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...

Indizes sind immer gut.   ;-)
Fuer Deine Loesung spricht in der Tat die geringere Anzahl Tabellen.
btw - Was machst Du, wenn eine Liste aller 'Artikel' angefordert ist, z.B. fuer Exportzwecke. - Welche Laufzeiten erwartest Du dann?

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)?

"It depends"

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)?

No comment.   ;-)

[Beispiele]

Danke.

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.

Ich haette eine Zuordnung ins Auge gefasst, wo z.B. die Kategorie immer in Ebene 3 landet, mithilfe von "Dummies".

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.

Hatte mal was von hunderttausenden Datensaetzen und von einer sehr variablen Kategoriesierung in Erinnerung.

Du kannst Dich ja mal melden und zur Umsetzung berichten. - Dein Loesungsansatz ist ja _vielleicht_ wirklich gut.   ;-)

Gruss,
Lude

[Andreas Korthaus]

Hi!

danke fuer Eure Geduld! Ich hab's jetzt wohl so halbwegs kapiert. - Bin ja kein "SQL-Experte".   ;-)

Nicht? Dann war das jemand anders der das mal von sich behauptet hat :)

(Allerdings verstaerkt sich bei mir der Eindruck, dass Du "nur" Datensaetze speichern willst, in diesem Fall 'Artikel', die kategorisiert werden sollen.

Ja, darum geht es, warum "nur"? Was hast Du denn gedacht?

• Das habe ich auch schon gemacht - bei mir haben bisher aber immer insgesamt drei "starre" Kategorien und Unterkategorien gereicht. - Kategoriesierung mithilfe von vier Kategorien und dann noch "dynamisch"? Das war fuer mich einfach zuviel.)

es geht ja gerade darum, dass dei Strukturierung flexibel ist. Ich habe keien festen Kategorieren, sondern halt eine komplexe Baumstruktur, wie inzwischen  mehrfach beschrieben. Die soll mind. 5 Ebenen tief sein können(bei meiner Version können die "unendliche" tief sein), und Produkte sollen den entsprechenden Kategorien auf allen Ebenen zuzuordnen sein.

dann mach mal eine Zeitmessung und Du wirst staunen.

Das kann ich mangels Daten nicht machen, aber vielleicht generiere ich mir mal ein paar, mal sehen. Aber ich bin mir sehr sicher dass man isn so einer wirklich winzigen Tabelle nur UNterschide im Millisekunden-Berreich bekommen wird - bei einer Abfrage.

Insbesonders das "rekursive Element", realisiert mithilfe von "umgebender Programmlogik", "haut rein".

Klar, aber das mache ich ja nie auf einmal, sondern wie im vorherigen Prosting beschrieben kommt pro Request imme rnur eine SQL-Abfrage - maximal 2 wenn es keine Unterkategoriern gibt. Das ist also vollkommen irrelevant.

Indizes sind immer gut.   ;-)

Wie würdest Du di indices legen bei den Anfragen dei ich zuvor beschrieben habe?

btw - Was machst Du, wenn eine Liste aller 'Artikel' angefordert ist, z.B. fuer Exportzwecke. - Welche Laufzeiten erwartest Du dann?

Wenn nur die Liste der Artikel angefordert ist brauche ich ja nur eine einfache SQL-Abfrag auf die Artikel-Tabelle. Wenn ich in der Import-Datei auch die Kategorien brauche, dann mache ich das halt noch mit einem LEFT JOIN auf die Struktur-Tabelle, das dauert dann vielleicht etwas länger, kommt aber im Gegensatz zu den zuvor beschreibenen Anfragen sehr selten vor, ist also ebenfalls nicht vergleichbar relevant, außerdem wird selbst das noch sehr schnell gehen. Guck Dir mal die Suche dieses Forums an, wie lange die braucht um 150 MB zu durchsuchen, das ist unglaublich schnell, und die macht das immerhin linear, das heißt es wird eine Flat-File Wort für Wort durchgegangen und auf Treffer überprüft. Eine Datenbank mit vernünftigen Indices ist da erheblich schneller, außerdem muss ich nicht im gesamten TExt suchen, sondern ich suche direkt über IDs, was den größten Unterschied ausmacht. Wenn ich 100.000 IDs habe wird nur ein Index mit MEDIUMINT(SMALLINT wäre wohl doch zu klein, maximal 65.535 IDs, da will ich lieber auf Nummer sicher gehen), jedenfalls wären das 300.000 Bytes also knapp 300 KB durchsucht. Das ist _sehr_ schnell, und 100.000 Datensätze sind eigentlich absolut unwahrscheinlich. Ggfs. das auslesen der so ermittelten Daten würde bei Dir genauso anfallen, da Du ja dieselben Daten willst.

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)?

"It depends"

"whereof"?

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.

Hatte mal was von hunderttausenden Datensaetzen und von einer sehr variablen Kategoriesierung in Erinnerung.

Nein, 100.000 habe ich also absolut pessimistischste Obergrenze Angegeben - für Produkte(hatte iah glaube ich falsch formuliert), und für Struktur 10.000.

Also,
Tabelle "struktur":
ID: MEDIUMINT (3 Byte)
Parent_ID: MEDIUMINT (3 Byte)
Titel: CHAR(32) (32 Byte)

pro Datensatz also 38 Byte

38 Byte * 10.000 = kanpp 400 KB

Tabelle "produkte":

ID: MEDIUMINT (3 Byte)
Struktur_ID: MEDIUMINT (3 Byte)
Titel: VARCHAR(32) (im Schnitt vielleicht 16 +1)
Beschreibung: TEXT (im Schnitt vielleicht 256 + 2)
Spezifikation: TEXT (im Schnitt vielleicht 256 + 2)
Bild: VARCHAR(32) (im Schnitt vielleicht 16 +1)

pro Datensatz also: 3+3+17+17+258+258

ca. 550 Byte * 100.000 = ca. 55 MB

Heißt also, solange ich nur auf die Struktur-Tabelle zugreife spielt Performance keine Rolle, und selbst die Produkte-ZTabelel ist nicht wirklich groß. Und da ich ja nur nach der Kategorie_ID und der ID filtere, kann ich jeweils die wie oben beschriebenen sehr kleinen Indices verwenden. Also sollt edas kein Problem machen. Problematisch wäre es wenn ich auch die Inhalte der TEXT-Felder durchsuche, aber das habe ich nicht vor, und das wäre bei jeder Implementierung das Problem.

Du kannst Dich ja mal melden und zur Umsetzung berichten. - Dein Loesungsansatz ist ja _vielleicht_ wirklich gut.   ;-)

Ich hoffe...

Grüße
Andreas

[Klaus Mock]

Hallo,

Die Datensätze, also die Artikel, würde ich ja im Augenblick auch in einer DB speichern,

Hm, vielleicht speicher ich die Struktur doch lieber in einer Tabelle, halt immer mit ID und Parent_ID, wie wie in Henryks PHP/MySQL Forums-Artikel?

Finde ich an sich auch als bessere Lösung.
Da will ich Dir gleich lange Zähne machen und  von einem Feature beiOracle erzählen. Damit kann man nämlich auch rekursive Abfragen auf Tabellen machen, die mit sich so einer Parent/Child-Beziehung steht.
Ein
SELECT LEVEL, id, spalte, noch_ne_spalte
  FROM Tabelle
  START WITH id_parent is null
  CONNECT BY  PRIOR ID = id_parent

würde dann eine ganze Struktur ausgeben. (*hehehe*)

Grüße
  Klaus

[Lude]

Hi,

Die Datensätze, also die Artikel, würde ich ja im Augenblick auch in einer DB speichern,

Hm, vielleicht speicher ich die Struktur doch lieber in einer Tabelle, halt immer mit ID und Parent_ID, wie wie in Henryks PHP/MySQL Forums-Artikel?

Finde ich an sich auch als bessere Lösung.
Da will ich Dir gleich lange Zähne machen und  von einem Feature beiOracle erzählen. Damit kann man nämlich auch rekursive Abfragen auf Tabellen machen, die mit sich so einer Parent/Child-Beziehung steht.
Ein
SELECT LEVEL, id, spalte, noch_ne_spalte
  FROM Tabelle
  START WITH id_parent is null
  CONNECT BY  PRIOR ID = id_parent

ist das nicht _durch und durch_ boese, wenn man an die Integritaeten denkt?

Gruss,
Lude

[Klaus Mock]

Hallo,

SELECT LEVEL, id, spalte, noch_ne_spalte
  FROM Tabelle
  START WITH id_parent is null
  CONNECT BY  PRIOR ID = id_parent

ist das nicht _durch und durch_ boese, wenn man an die Integritaeten denkt?

Wo siehst Du ein Problem mit den Integritaeten ?

Grüße
  Klaus

[Andreas Korthaus]

Hi!

Hm, vielleicht speicher ich die Struktur doch lieber in einer Tabelle, halt immer mit ID und Parent_ID, wie wie in Henryks PHP/MySQL Forums-Artikel?

Finde ich an sich auch als bessere Lösung.

Hm, und da dachte ich doch glatt ich hätte das erste mal eine Möglichkeit gefunden XML auch mal produktiv einzusetzen :-(
Naja, aber Du hast schon recht, vor allem durch die Notwendigkeit der Verknüpfung mit den Produkten ist XML nicht merh so optimal.
Ganz vielleicht wandel ich dann halt die Konfigurations-Datein in XML-Format um, mal sehen ;-)

Da will ich Dir gleich lange Zähne machen und

Was ist das denn für ein Spruch? ;-)

von einem Feature beiOracle erzählen. Damit kann man nämlich auch rekursive Abfragen auf Tabellen machen, die mit sich so einer Parent/Child-Beziehung steht.
Ein
SELECT LEVEL, id, spalte, noch_ne_spalte
  FROM Tabelle
  START WITH id_parent is null
  CONNECT BY  PRIOR ID = id_parent

würde dann eine ganze Struktur ausgeben. (*hehehe*)

Wie wird das denn ausgegeben? Wenn ich das jetzt vn PHP aus machen würde, was bekäme ich dann zurück? Einen Array oder ein Objekt mit der fertigen Struktur?

Hm, hm, hm.... naja, wie es der Zufall will wird auch gerade überlegt welches RDBMS denn zu verwenden ist. Naja, leider bin ich zur Zeit noch auf PHP beschränkt, daher wird die Wahl der DB doch etwas eingeschränkt. Gut, Oracle könnte mir auch gefallen, obwohl ich da so gut wie keine Erfahrung mit habe, aber man hört ja dies und das... nur mind. 20.000 EUR allein für die DB-Lizenzten auszugeben, das ist einfach nicht drin. Aber was wären die Alternativen? OK, DB2 würde mir auch sehr gefallen, nur konnte ich da bis heute keine Schnittstelle bei PHP finden (obwohl es bei ./configure den --with-db2-dir Parameter gibt!!!). Und ODBC will ich nicht ernsthaft in Erwägung ziehen. OK, dann wirds schon enger, MSSQL-Server ist auch schlecht auf Unix-Maschinen(vielleicht über wine, aber lassen wir das ;-)). Und dann vielleicht MySQL, aber das würde ich bei sensiblen Daten mit den INNO-DB Treibern nicht ernsthaft in Erwägung ziehen, die sind einfach noch zu neu und zu wenig getestet, zumal MySQL ja im eigenen Manual schreibt dass die nicht so gut getestet sind wie beispielsweise bei PostgreSQL! OK, PostgreSQL ist eine Alternative, nur weiß ich nicht in wiefern PostgreSQL mit wirklich professionellen Produkten wie eben DB2 & Co. mithalten kann, vor allem von wegen Stabilität, Datensicherheit, Datenintegrität..., außerdem sind Namen wie Oracle, DB2... bei Kunden immer wieder gerne gesehen...

Naja, ein Thema für sich ;-)
Gibt ja noch ne Menge daneben, Interbase, Sybase, Adabas, SAP-DB, Firebird, Informix... was ist denn mit denen? Ist da eine von besser als PostgreSQL, halt unter oben genannten Kriterien?

Viele Grüße
Andreas

[Klaus Mock]

Hallo,

Hm, und da dachte ich doch glatt ich hätte das erste mal eine Möglichkeit gefunden XML auch mal produktiv einzusetzen :-(

Irgendwie habe ich vergessen, beim ersten  Posting eine Begründung anzugeben.
Besser finde ich es, weil wenn DU die Artikel sowieso schon in einem RDBMS speichern willst, halte ich es für besser, wenn Du nicht 'aus dem System herausspringst'. Daten, die zusammengehören, auf zwei unterschiedliche Medien auzuteilen, finde ich nicht so toll.

Da will ich Dir gleich lange Zähne machen und
Was ist das denn für ein Spruch? ;-)

ooch, ich dachte nur so... *gg*

SELECT LEVEL, id, spalte, noch_ne_spalte
  FROM Tabelle
  START WITH id_parent is null
  CONNECT BY  PRIOR ID = id_parent

würde dann eine ganze Struktur ausgeben. (*hehehe*)

Wie wird das denn ausgegeben?

Als ganz normale Menge an Datensätzen (nur sortieren sollte man dann nicht mehr, sonst zerwürfelt es einem die Struktur ;-)

Gut, Oracle könnte mir auch gefallen, obwohl ich da so gut wie keine Erfahrung mit habe, aber man hört ja dies und das...

Also so nebenbei würde ich das nicht mehr machen. Ich hatte bisher immer das Glück einige erfahrene Oracle-DBA's um mich zu haben, wenn ich damit zu tun hatte (und habe). Ohne qualifizierte Unterstützung ist das sicherlich ein Höllenritt. Sie kann zwar wirklich viel, obwohl ich auch schon einiges vermißt habe, aber man muß bei allem schon sehr genau überlegen, was das alles für Konsequenzen hat. Andere Datenbanken sind da eher für 'Set it & forget it' geeignet.

nur mind. 20.000 EUR allein für die DB-Lizenzten auszugeben, das ist einfach nicht drin.

_Das_ kommt dann ja auch noch dazu. Aber wenn die Kunden es so haben wollen. Ich bin mir zwar nicht sicher, aber afaik ist die Benutzung zumindestens für Entwicklung von Anwendungen kostenfrei.

Von DB2 weiß ich lediglich, daß es sie gibt und daß sie von IBM kommt.
ODBC ist keine Datenbank, sonder eine Client-Schnittstelle, vergleichbar mit DBI oder JDBC.

MSSQL ist, wie Du schon angedeutet hast, auf Windows-Servern zu Hause, kann aber in den aktuellen Versionen auch schon recht viel.
Die Sybase-Datenbank ist dem MSSQL-Server ziemlich ähnlich, kein Wunder, waren bei in ihren früheren Versionen einmal dasselbe.

Auch zu PostgreSQL kann ich auch nichts sagen, das gleiche gilt für Adabas bzw. SAP-DB und Informix.

Bleibt noch Interbase und Firebird. Interbase 6.0 und Firebird 1.0 sind eigentlich auch ein Produkt, wobei Firebird aus Interbase 6.0 entstanden ist, da diese Interbase-Version ja Open-Source ist. Frühere Interbase Versionen und alle ab 6.5 sind wieder Closed-Source, ein typisches Zeichen für die Firmenpolitk bei Borland.

Bleiben wir bei Firebird.
Eigentlich gefällt mir die DB recht gut. Sie hat zwar einige Eigenheiten, aber mit denen kann man recht gut leben.
Sie beherrscht neben Tabellen (no na *g*) auch noch Views, Sequences (Generatoren), Trigger, Stored Procedures, Domains (damit kann man quasi logische Datentypen definieren), Transaktionen und User-defined-Funktions (UDF). Letzteres macht so ziemlich die Spärlichkeit bei eingebauten Funktionen wett.
Auch Hot-Backups können dank interner Daten-Versionierung gemacht werden. Und der Transfer einer kompletten DB von hinnen nach dannen ist an sich auch ein Kinderspiel.

Die neue Version, die anscheinend kurz vor der offiziellen Release steht, kann dann auch noch so Sachen wie Savepoints (also so was ähnliches wie Transaktionen in einer Transaktion) LIMIT und son Zeuchs.

Wie gesagt, mir gefällt sie schon recht gut, vor allem bei kleinem bis mittlerem Datenaufkommen (sagen wir mal bis einer Datenbankgröße von einigen 100MByte).

Grüße und HTH
  Klaus

[Andreas Korthaus]

Hi Klaus!

Besser finde ich es, weil wenn DU die Artikel sowieso schon in einem RDBMS speichern willst, halte ich es für besser, wenn Du nicht 'aus dem System herausspringst'. Daten, die zusammengehören, auf zwei unterschiedliche Medien auzuteilen, finde ich nicht so toll.

Ja, das habe ich mir auch gedacht. Was hälst Du denn von er Idee die Struktur mehr oder weniger persistent in einem PHP-Array zu speichern?

Gut, Oracle könnte mir auch gefallen, obwohl ich da so gut wie keine Erfahrung mit habe, aber man hört ja dies und das...

Also so nebenbei würde ich das nicht mehr machen. Ich hatte bisher immer das Glück einige erfahrene Oracle-DBA's um mich zu haben, wenn ich damit zu tun hatte (und habe). Ohne qualifizierte Unterstützung ist das sicherlich ein Höllenritt. Sie kann zwar wirklich viel, obwohl ich auch schon einiges vermißt habe, aber man muß bei allem schon sehr genau überlegen, was das alles für Konsequenzen hat.

Ja, da hast Du vollkommen Recht. Oracle würde vermutlich die Entwicklungskosten deutlich in die Höhe treiben, und dazu die Lizenzkosten um ein vielfaches erhöhen. Das wiederum tribt am Ende den Preis für die Software in die Höhe, was natürlich nicht so schön ist, udn nach Möglichkeit vermieden werden soll.

_Das_ kommt dann ja auch noch dazu. Aber wenn die Kunden es so haben wollen. Ich bin mir zwar nicht sicher, aber afaik ist die Benutzung zumindestens für Entwicklung von Anwendungen kostenfrei.

Ja, aber man braucht ja spätestens wenn es Produktiv eingesetzt wird Lizenzen, also bringt das auch nicht viel. Außerdem wird bei größeren Rechnern und ein paar mehr Usern schnell _sehr_ viel teurer.

Von DB2 weiß ich lediglich, daß es sie gibt und daß sie von IBM kommt.

Ist immer hin nach Oracle am meisten verbreitet, wenn auhc vornehmlich auf IBMs Mainframes, aber auch dei Linux-Version macht wohl viel Boden gut. Auf jeden Fall ist DB2 _erheblich_ günstiger als Oracle. Nur ist es schwer objektive Informationen zu den jeweili Vor- und Nachteilen zu erhalten, denn meist finden man nur white-papers, meist von oracle und die lassen dann kein gutes Haar an DB2, sei noch unzuverlässiger als MSSQL Server... aber ich kann diese Aussagen nicht wirklich bewerten, ich bin da lieber etwas vorsichtiger, denn IBM führt Studien an die dasselbe von Oracle behaupten...

ODBC ist keine Datenbank, sonder eine Client-Schnittstelle, vergleichbar mit DBI oder JDBC.

Klar ;-)
Habe übrigens herausbekommen, dass PHP DB2 doch über die native Schnittstelle unterstützt, zwar verwendet man die odbc-Funktionen, aber diese verwenden kann kein ODBC-Interface, sondern das native DB2 CLI. Wie gut diese Schnittstelle allerdings ist/sein kann kann ich nicht beurteilen.

Die Sybase-Datenbank ist dem MSSQL-Server ziemlich ähnlich, kein Wunder, waren bei in ihren früheren Versionen einmal dasselbe.

Funktioniert wenigstens auf Linux, und gehört ebenfalls zu den 5 größten.

Auch zu PostgreSQL kann ich auch nichts sagen, das gleiche gilt für Adabas bzw. SAP-DB und Informix.

SAP-DB ist ja wohl aus ADABAS hervorgegangen und frei verfügbar. Mehr weiß ich da auch nicht. Informix war früher mal sehr verbreitet, wurde aber von IBM aufgekauft und verliert an Bedeutung, naja, eien objektive Meinung über die Qualität und Unterschiede mehrerer DBs zu bekommen ist nicht einfach ;-)

PostgreSQL ist schon wirklich nett

Transactions
Procedural languages (PL/pgSQL und PL/Perl)
Fully ACID compliant
ANSI SQL compliant
Referential Integrity
Replication
Native interfaces for ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python, and Ruby
Rules
Views
Triggers
Unicode
Sequences
Inheritance
Outer Joins
Sub-selects
An open API
Stored Procedures
Support for UNION, UNION ALL and EXCEPT queries
Extensible data type system providing for custom, user-defined datatypes and rapid development of new datatypes
Cross-database compatibility functions for easing the transition from other, less SQL-compliant RDBMS
...

Und PostgreSQL gibt es schon wirklich lange, und da sehe ich auch den Vorteil gegenüber MySQL, ist ja alles schön und gut dass es inzwischen Transaktionen und Fremdschlüssel gibt, aber leider noch nicht so besonders lange, und es wird nicht oft benutzt, das ganez ist noch nicht wirklich gut ausgetestet, so dass man sich beruhigt 100%ig drauf verlassen könnte. Und das geben did Entwickler ja selbst im Manual zu, und gerade das ist mir bei der Wahl des RDBMS besonders wichtig.

Das wichtigste Kriterium ist, dass die Wahrscheinlichkeit, dass zu einem bestimmten Zeitpunkt bestimmte Daten nicht oder nicht korrekt vorliegen minimiert wird - nicht um _jeden_ Preis(Oracle), aber es darf durchaus was kosten. Denn wenn so etwas passiert wird das am Ende sicher teurere als eine komerzielle DB-Lizens. Nur ist es auf der anderen Seite ja auch Quatsch Geld für sowas auszugeben, wenn eine freie Lösung wie PostgreSQL den komerziellen Systemen hier in nichts nachsteht - was mich allerdings wundern würde. Auf jeden Fall sollte die Software auf Linux wirklich zu Haus sein, nicht dass es hier probleme gibt da ein System "auf dei Schnelle" nach Linux portiert wurde, oder dass die Schnittstelle von PHP schlecht implementiert ist.

Bleiben wir bei Firebird.
Eigentlich gefällt mir die DB recht gut. Sie hat zwar einige Eigenheiten, aber mit denen kann man recht gut leben.

Von Firebird habe ich eigentlich nur in einem CT-Artikel mal was gelesen, naja, hab es mir noch nicht nähr angeschaut, muss den Artikel nochmal lesen und mir das ggfs. nochmal neäher ansehen.

Sie beherrscht neben Tabellen (no na *g*) auch noch Views, Sequences (Generatoren), Trigger, Stored Procedures, Domains (damit kann man quasi logische Datentypen definieren), Transaktionen und User-defined-Funktions (UDF). Letzteres macht so ziemlich die Spärlichkeit bei eingebauten Funktionen wett.
Auch Hot-Backups können dank interner Daten-Versionierung gemacht werden. Und der Transfer einer kompletten DB von hinnen nach dannen ist an sich auch ein Kinderspiel.

Ist dann also von den Features ein wenig vergleichbar mit PostgreSQL, welches ich hier glaube ich vorziehen würde wegen der guten Schnittstelle in PHP. Wie/ob man auf Firebird aus PHP zugreifen kan weiß ich nicht, nur tue ich mich immer schwer mit ODBC, damit hatte ich schonmal arge Probleme, und das unter Windows wo es ja eigentlich herkommt.

Die neue Version, die anscheinend kurz vor der offiziellen Release steht, kann dann auch noch so Sachen wie Savepoints (also so was ähnliches wie Transaktionen in einer Transaktion) LIMIT und son Zeuchs.

Wie gesagt, mir gefällt sie schon recht gut, vor allem bei kleinem bis mittlerem Datenaufkommen (sagen wir mal bis einer Datenbankgröße von einigen 100MByte).

Ich werde es mir auf jeden Fall nochmal näher ansehen.

Jedenfalls vielen Dank für Deine Tipps!

Viele Grüße
Andreas

[Klaus Mock]

Hallo,

Was hälst Du denn von er Idee die Struktur mehr oder weniger persistent in einem PHP-Array zu speichern?

Wenn es brauchbar implementiert ist...;-)
Für die Wartung der Daten ist imho die Tabelle mit den 'Ordnern' und einer jeweiligen Parent-ID am einfachsten. Das Aufbereiten dieser Daten für eine Visualisierung ist dann schon etwas anderes, weil Du wahrscheinlich ausprogrammierte rekursive Abfragen vermeiden willst.

Daher solltest Du Dir imho überlegen, wie die Daten am besten für die Visualisierung daher kommen sollten. Dementsprechend könntest Du dann beispielsweise bei der Änderung der rohen Strukturdaten schon eine Überleitung in eine passende Darstellungsform implementieren. Wenn Du also, sagen wir mal, zum Schluß kommst, Daß Dir eine Pfadangabe wie Lebensmittel/Getränke/Milchprodukte für die Darstellung am besten erscheint, dann könntest Du bereits nach dem Schreiben einer Änderung (inklusive Insert) diesen Pfad zusammen bauen und dem entsprechend abspeichern( Wobei das allerdings nicht ganz trivial ist, wenn z.B. ein 'Ordner' verschoben wird).

PostgreSQL ist schon wirklich nett

Ich habe mal auf die Schnelle die Dokumentation durchflogen, und das klingt alles recht vernünftig, was da so geboten wird. Daher will ich mir einmal in nächster Zeit das Teil genauer ansehen. Das könnte für ein in Kürze aktuell werdendes Projekt interessant sein.

BTW: mittels der Möglichkeit in PostgreSQL Funktionen in der Datenbank zu schreiben könnte ich mir vorstellen, daß Du eventuell die Daten aus den Struktur-Tabelle auch on-the-fly aufbereiten kannst. WIe performant so etwas sein  wird, kann ich natürlich nicht sagen.

Wie/ob man auf Firebird aus PHP zugreifen kan weiß ich nicht,

Afaik wird Firebird direkt untestützt, wie gut diese Unterstützung ist, kann ich mangels PHP-Erfahrung nicht sagen.

nur tue ich mich immer schwer mit ODBC, damit hatte ich schonmal arge Probleme, und das unter Windows wo es ja eigentlich herkommt.

ODBC an sich ist, so finde ich, nicht schlecht. nur sind die Treiber für die einzelnen Datenbanken teilweise ziemlicher Mist.

Grüße
  Klaus

[Andreas Korthaus]

Hi Klaus!

Was hälst Du denn von er Idee die Struktur mehr oder weniger persistent in einem PHP-Array zu speichern?

Wenn es brauchbar implementiert ist...;-)

Naja, erst dachte ich dran dass in Javascript zumachen, also den kompletten Array mit der Struktur in einer externen Javascript-Datei zu speichern, das wäre das mit Abstand effizienteste, da die nur einmal übertragen werden muss, da sich die Struktur nur selten ändern wird. Das wird nur problematisch wenn es ein paar mehr Kategorien, und  außerdem müssten alle Produkte da mit rein, das würde dann sehr groß und damit unbrauchbar.

Für die Wartung der Daten ist imho die Tabelle mit den 'Ordnern' und einer jeweiligen Parent-ID am einfachsten. Das Aufbereiten dieser Daten für eine Visualisierung ist dann schon etwas anderes, weil Du wahrscheinlich ausprogrammierte rekursive Abfragen vermeiden willst.

Sicher, daher werde ich das nur machen, wenn sich was ändert. D.h. bei einer Änderung der Struktur werde ich anschließend den mehrdimensionalen Array mit der Struktur neu erstellen, mit der Funktion var_export in eine Datei schreiben, dann habe ich nämlich eine Text-Datei in der sowas steht:

<?php
$struktur = array(
              'Lebensmittel' => array('Molkereiprodukte' => array('Milchprodukte','Quarkprodukte'),
              ...
);
?>

den kann ich dann _durekt_ verwenden(per include), da es sich um PHP-Code handelt.

Daher solltest Du Dir imho überlegen, wie die Daten am besten für die Visualisierung daher kommen sollten. Dementsprechend könntest Du dann beispielsweise bei der Änderung der rohen Strukturdaten schon eine Überleitung in eine passende Darstellungsform implementieren.

Ja, das wäre ja sowas wie mit Javascript, aber da ist halt das Prblem mit der Größe, bei 10.000 Arikeln kann der Array mehrere MB groß sein,  auch wenn ich das komprimiert ausliefere ist das viel zu groß.

Wenn Du also, sagen wir mal, zum Schluß kommst, Daß Dir eine Pfadangabe wie Lebensmittel/Getränke/Milchprodukte für die Darstellung am besten erscheint, dann könntest Du bereits nach dem Schreiben einer Änderung (inklusive Insert) diesen Pfad zusammen bauen und dem entsprechend abspeichern( Wobei das allerdings nicht ganz trivial ist, wenn z.B. ein 'Ordner' verschoben wird).

Daher werde ich die Struktur komnplett neu bauen, bei jeder Änderung, immer basierend auf dem was in der Tabelle der DB steht. Aufgrund der zu erwartenden Größe, werde ich beim klicken auf eine Unterkategorie einen Request an den Server senden, und entsprechend die Einträge für diese Unterkategorie ermitteln. So werde nicht mehr Daten übertragen als notwendig, dafür ist es nicht so schön flüssig wie bei Javascript, naja.

PostgreSQL ist schon wirklich nett

Ich habe mal auf die Schnelle die Dokumentation durchflogen, und das klingt alles recht vernünftig, was da so geboten wird. Daher will ich mir einmal in nächster Zeit das Teil genauer ansehen. Das könnte für ein in Kürze aktuell werdendes Projekt interessant sein.

Ich habe auch nich wirklich vie Erfahrung damit, habe das seit kurzem erst auf meinem Server installiert und stelle gerade von MySQl 4 um.

BTW: mittels der Möglichkeit in PostgreSQL Funktionen in der Datenbank zu schreiben könnte ich mir vorstellen, daß Du eventuell die Daten aus den Struktur-Tabelle auch on-the-fly aufbereiten kannst. WIe performant so etwas sein  wird, kann ich natürlich nicht sagen.

Hm, muss ich mal sehen, aber da ich das eh nicht on-the-fly machen werde habe ich damit weniger Probleme, und ich vermeide das dann doch lieber, falls ich dann mal auf eine andere RDBMS(DB2...) umstellen müsste, dann habe ich mit solchen Sachen nämlich größere Probleme.

Wie/ob man auf Firebird aus PHP zugreifen kan weiß ich nicht,
Afaik wird Firebird direkt untestützt, wie gut diese Unterstützung ist, kann ich mangels PHP-Erfahrung nicht sagen.

Ja, da sgeht glaueb ich über dei Interbase Funktionen, ich hoffe nur nicht das an der Interbase-API was verändert wurde. Nur hätte ich da wohl eher ein problem ein Produkt was gerde frische neu Programmiert wurde einzusetzen. Sicher ist es jetzt schneller, aber da sind zwangsweise noch sehr viele Fehler drin, und das ist das letzte was ich brauche, die Performance ist zwar nicht unwichtig, aber im Vergleich zu solchen Problemen eher vernachlässigbar. Das Problem sehe ich auch bei SAP DB, was ich da so gelesen habe, ist das doch schonmal recht instabil. Vermutlich ist das ähnlich bei bei Oracle, dass man das durchaus sehr stabil hinbekommt, aber dazu braucht man echte Experten, SAP empfiehlt ja auch dass man unbedingt für 60.000 USD den Support mitbestellen soll, will man es produktiv einsetzen. Das ist der Vorteil von MySQL, das ist wirklich sehr einfach und gut dokumentiert, dass man damt schon alleine klarkommt, wie das bei PostgreSQL ist muss ich aber erst noch sehen. Und auch bei DB2 und Co. weiß ich nicht wie unkompliziert die sind, aber vermutlich eher in Richtung Oracle als in Richtung MySQL.

nur tue ich mich immer schwer mit ODBC, damit hatte ich schonmal arge Probleme, und das unter Windows wo es ja eigentlich herkommt.

ODBC an sich ist, so finde ich, nicht schlecht. nur sind die Treiber für die einzelnen Datenbanken teilweise ziemlicher Mist.

Ja, genau das ist es, native CLI's sind mit da erheblich lieber.

Viele Grüße
Andreas

[Andreas Korthaus]

Hallo!

Ich habe noch meonen Baum wie unten:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
    Quarkprodukte
  Backwaren

Jetzt möchte ich mit der HTML-Oberfläche so Dinge machen wie

• Kategorieren nach oben verschieben
• Kategorieren nach unten verschieben
• Kategorie eine Ebene nach oben
• Kategorie eine Ebene nach unten

Nur - wie speichere ich diesen Zustand in PHP? Ich habe jetzt also nicht mehr wie in einen Thread-Baum im Forum eine feste Struktur, sondern kann die wie ich will verändern, indem ich Kategorien verschiebe.

Ich könnte halt bei jedem Element seine Parent_ID speichern (was ich ja eh vorhabe), somit habe ich ja durchaus die Möglichkeit absolut flexibel die Struktur zu verändern. Problem, wenn ich jetzt wie oben z.B. "Quarkprodukte" einen Punkt nach oben verschieben will, wie speichere ich dann diese Reihenfolge? Oder speicher ich eine ID für dei Reihenfolge in jeder KAtegorie, also in der Kategorie Molkereiprodukte speichere ich bei Milchprodukte 1, bei Quarkprodukte die 2, wenbn ich dann Quarkprodukte nach oben verschiebe sehe ich erst in der DB nach es in der Kategorie einen Eintrag 2-1 gibt, wenn ja wird die ID auf die alte ID von Quarkprodukte(2) gesetzt und ich trage für Quarkprodukte die 2-1=1 ein.

Hat jemand ne bessere Idee, mir würde es reichen wen ich das ien ienem Array speichern könnte, wobei das auch irgendwann fest gespeichert werden muss.

Ich hoffe Ihr versteht was ich meine ;-)

Grüße
Andreas

[Andres Freund]

Hi Andreas,

Hat jemand ne bessere Idee, mir würde es reichen wen ich das ien ienem Array speichern könnte, wobei das auch irgendwann fest gespeichert werden muss.

Dieses ganze Szenario, würde meiner Meinung nach, wieder für eine seperate Speicherung der Struktur sprechen, etwa in xml. Diese Struktur, könntest du dann in einem Record speichern den du in einer Datei cachest, den du nat. nicht immer neu generierst, sondern nur bei Änderungen der Struktur.
Dadurch könntest du, wenn jede Kategorie, eine ID hätte, das ganze recht einfach zuordnen.

Von der XML Struktur, würde ich das ähnlich machen, wie du das vorgeschlagen hast. Danach musst du das ja "nur" noch die XML-Struktur, in einem Record aus Arrays abbilden. Ich würde das ganze aus Arrays zusammenbauen, die solange auf weitere arrays verweisen, bis man bei der untersten Ebene angelangt sind. Diese Art der Struktur, ist meiner Meinung nach wesentlich flexibler, als die die mit in der Tabelle gespeichert wird. So bist du auch nicht auf die 5 Ebenen in der Tabelle beschränkt, und meiner Meinung nach, dürfte der Rechenaufwand eher geringer ausfallen, als einen, rein in einer relationalen DB, gespeicherten, da du nicht mehrere Anfragen braucht, um die komplette Struktur herauszufinden, bzw. die ganze Tabelle abfragen musst.

Ich hoffe Ihr versteht was ich meine ;-)

Und ich hoffe, das ich dich nicht komplett falsch verstanden habe ;-)

Grüße Andres

[Andreas Korthaus]

Hallo Andres!

Dieses ganze Szenario, würde meiner Meinung nach, wieder für eine seperate Speicherung der Struktur sprechen, etwa in xml.

das war auch mein erster Gedanke ;-)
Nur, was bringt das? Das Problem ist ja, dass ich XML immer umwandeln muss, und das macht man in PHP gemein hin indem man die XML-Datei komplett parst und in einen Array schreibt. Mit diesem Array arbeite ich dann wenn ich Daten ausgeben will. Daher ist die Speicherung eigentlich gar nicht so relevant, der große Unterschied ist, dass ich bei XML immer alles parsen muss, und bei einer DB-Lösung SELECTiere ich direkt die Datensätze die ich brauche udn habe so nur eien Bruchteil des Baums. Das Problem ist auch weniger die oben angesprochenen Änderungen in der Struktur(hoch, runter...) in XML darstellen zu kömnnen, sondern in einem Array. Wie vertausche ich denn 2 Elemente eines Arrayy, bzw. wie verändere ich dei Reihenfolge der Elemente? Solche Sachen mache ich nicht gerne, weil ich imme rdas Gefühl habe mir potentielle "Sollbruchstellen" einzuhandeln, obwohl das glaube ich in der Praxis kein wirkliches Problem ist, oder? Oder würdet Ihr einen ganz anderen Weg gehen die Struktur darzustellen und zu veränern? Egal in welcher Programmiersprache, ist nicht auf PHP beschränkt, aber vielleicht gibt es ja einen besseren Weg als das mit einem Array und jeweils den Unterbaum als Array an das Elternelement als Element hängen, nur wie bringe ich das die Reihenfolge unter? Ist irgendwie nicht konsistent. Bedenke das ich ja nicht nur eine ID brauche, sondern auch den Namen der Kategorie um das ganze ausgeben zu können!

Der "medienbruch"(XML<->DB) ist mir im Augenblick trotzdem wieder etwas egaler als vorher, nur zweifele ich ob XML hier was bringt ;-)

Diese Struktur, könntest du dann in einem Record speichern den du in einer Datei cachest, den du nat. nicht immer neu generierst, sondern nur bei Änderungen der Struktur.

Was für ein "Record"? Ich greife immer nur auf einen Teil des Baums zu, nie auf den ganzen, daher ist es eien Frage ob es Sinn macht jedesmal beim Auslesen die komplette Struktur parsen zu müssen.

Dadurch könntest du, wenn jede Kategorie, eine ID hätte, das ganze recht einfach zuordnen.

hm.?

Von der XML Struktur, würde ich das ähnlich machen, wie du das vorgeschlagen hast. Danach musst du das ja "nur" noch die XML-Struktur, in einem Record aus Arrays abbilden. Ich würde das ganze aus Arrays zusammenbauen, die solange auf weitere arrays verweisen, bis man bei der untersten Ebene angelangt sind. Diese Art der Struktur, ist meiner Meinung nach wesentlich flexibler, als die die mit in der Tabelle gespeichert wird. So bist du auch nicht auf die 5 Ebenen in der Tabelle beschränkt, und meiner Meinung nach, dürfte der Rechenaufwand eher geringer ausfallen, als einen, rein in einer relationalen DB, gespeicherten, da du nicht mehrere Anfragen braucht, um die komplette Struktur herauszufinden, bzw. die ganze Tabelle abfragen musst.

Ich will nie die ganze Struktur abfragen. Wie ich unten beschrieben habe (Daten-Struktur: [pref:t=53383&m=295932], stattfindende Abfragen: [pref:t=53383&m=296462]) wird pro request immer nur eine SQL-Abfrage auf die Struktur-Tabelle notwendig!

Vielen Dank und viele Grüße
Andreas

[Klaus Mock]

Hallo,

Innerhalb der Ebenen zu vershcieben ist noch relativ einfach. Da mußt DUbeim ausgewählten Element nur die Parent_ID (wenn es ein 'Ordner' ist), oder die 'Ordner'-ID(wenn es ein Produkt ist) verändern.

Die Reihenfolgen zu ändern ist dann schon etwas schwieriger. Du müßtest imho, wie Du auch schon angedacht hast, eine Positionsnummer einführen (am Besten je 'Ordner' eindeutig). Wenn Du nun die Position verschieben willst, dann mußt Du ermitteln, welche Positionsnummern des aktuellen Elements und des Elements vor bzw nach dem aktuellen ermitteln und diese dann vertauschen.

Grüße
  Klaus

PS: Vielleicht ist mein Lösungsansatz zu Deinen Aufgabe etwas zu stark von meiner aktuellen Arbeit geprägt, in der auch eine mehr oder weniger identische Teilaufgabe geforder ist. Die Begriffe sind zwar anders, aber es geht um das selbe Thema. Es geht dabei um einen generischen Client, wobei die einzelnen Informationsquellen (Shortcuts, Links oder wie auch immer) in mehreren Strukturbäumen eingehängt werden können. Der einzige wirkliche Unterschied ist der, daß bei dieser Lösung die 'Ordner' und die 'Shortcuts' in einer Tabelle verwaltet werden. Das erleichert die Sache mit den Positionsnummern doch etwas;-)

[Andreas Korthaus]

Hi!

Innerhalb der Ebenen zu vershcieben ist noch relativ einfach. Da mußt DUbeim ausgewählten Element nur die Parent_ID (wenn es ein 'Ordner' ist), oder die 'Ordner'-ID(wenn es ein Produkt ist) verändern.

Die Reihenfolgen zu ändern ist dann schon etwas schwieriger. Du müßtest imho, wie Du auch schon angedacht hast, eine Positionsnummer einführen (am Besten je 'Ordner' eindeutig). Wenn Du nun die Position verschieben willst, dann mußt Du ermitteln, welche Positionsnummern des aktuellen Elements und des Elements vor bzw nach dem aktuellen ermitteln und diese dann vertauschen.

Mein Problem ist zur Zeit weniger die Datenhaltung, eher das was wzischen Datenhaltung und Ausgabe kommt. Ich sollte mich wohl man von dem PHP-Array verabschieden und das direkt aus der DB in die Ausgabe überführen. Ich speicher dann nur noch einen Array mit den "aufgeklappten" Parent_IDs in der Session, entsprechend muss ich dann für jede darin enthaltenen ID die Unterketegoriene mir Reihenfolge ID aus der DB lesen, halt mit "order by reihenfolge_ID". Wobei, ich brauche zusätzlich noch die Information ob es Unterketegorien oder produkte in einer Kategorie gibt, das werden dann doch ein par Mehr Abfragen, da ich das für jede Kategorie machen muss.

Nur mal so:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
      1 Liter Frische Vollmilch
      1 Liter fettarme Milch
      0,5 Liter frische Vollmilch
    Quarkprodukte
  Backwaren

Das wird in der DB dann so abgebildet:

Tabelle "struktur":

ID | Parent_ID | Reihenfolge_ID | Titel
---+-----------+----------------+-------
1  | 0         | 1              | Lebensmittel
2  | 1         | 1              | Getränke
3  | 1         | 2              | Molkereiprodukte
4  | 3         | 1              | Milchprodukte
5  | 3         | 2              | Quarkprodukte
6  | 1         | 3              | Backwaren

Tabelle "produkte":

ID | Struktur_ID | Reihenfolge_ID | Titel                       | Beschreibung | Bild
---+-------------+----------------+-----------------------------+--------------+------------------------------
1  | 4           | 1              | 1 Liter Frische Vollmilch   | blabla1...   | schoene_milch_12345.jpg
2  | 4           | 2              | 1 Liter fettarme Milch      | blabla2...   | schoene_milch_12346.jpg
3  | 4           | 3              | 0,5 Liter frische Vollmilch | blabla3...   | schoene_milch_12347.jpg

Die "aktuelle Struktur", also welche Knoten des Baums aufgeklappt ist wird in der Session zwischengespeichert, und zwar so:

$aufgeplappte_Kategorien = array(0,1,3,4);

Dann frage ich das nacheinander ab:
SELECT ID,Titel FROM Struktur WHERE Parent_ID = 0 ORDER BY Reihenfolge_ID DESC
SELECT ID,Titel FROM Struktur WHERE Parent_ID = 1 ORDER BY Reihenfolge_ID DESC
SELECT ID,Titel FROM Struktur WHERE Parent_ID = 3 ORDER BY Reihenfolge_ID DESC
SELECT ID,Titel FROM Struktur WHERE Parent_ID = 4 ORDER BY Reihenfolge_ID DESC

Und jetzt wird es unschön, den ich muss ermitteln, in welchen Kategorien es Unterkategorien oder Produkte gibt:

Im Prinzip muss ich also nach jeder Abfrage oben in einer Schleife alle IDs der Ergebnisse durchegen so abfragen:

SELECT COUNT(*) FROM Struktur WHERE Parent_ID = $id
Und wenn das keine Ergebnisse liefert noch die Produkttabelle entsprechend abfragen. Das kommt mir jetzt auf einem wirder _sehr_ umständlich vor. Vielleicht mache ich das lieber mit einem Sub-Select und GROUP BY? Nur geht dann MYSQL nicht mehr, naja wäre auch nicht so schlimm...
Also da zweifele ich doch stark ob die Datenbank hier noch viel Sinn macht. Wobei natürlich auch über 100 Abfrageb ien einerm Script deutlich unter 1 Sekunde zu erledigen wären, naja.

Nochmal der Versuch das als PHP-Array zu halten:

Lebensmittel
  Getränke
  Molkereiprodukte
    Milchprodukte
      1 Liter Frische Vollmilch
      1 Liter fettarme Milch
      0,5 Liter frische Vollmilch
    Quarkprodukte
  Backwaren

Das Würde ich dann so machen

$struktur[1]['titel'] = 'Lebensmittel';
$struktur[1]['id'] = 0;
$struktur[1]['ukat'][1]['titel'] = 'Getränke';
$struktur[1]['ukat'][1]['id'] = 1;
$struktur[1]['ukat'][2]['titel'] = 'Molkereiprodukte';
$struktur[1]['ukat'][2]['id'] = 2;
$struktur[1]['ukat'][2]['ukat'][1]['titel'] = 'Milchprodukte';
$struktur[1]['ukat'][2]['ukat'][1]['id'] = 3;
$struktur[1]['ukat'][2]['ukat'][2]['titel'] = 'Quarkprodukte';
$struktur[1]['ukat'][2]['ukat'][2]['id'] = 3;
...

Aber das gefällt mir nicht wirklich. Ich habe das so gemachtn denn so kann ich einfach sehen ob in der Kategorie eine Unterkategorie kommt:

if($struktur[$id]['ukat']) {
  print "es gibt eine";
}

Außerdem kann ich die Untergruppen dann einfach abfragen:

foreach ($struktur[$id]['ukat'] as $tmp) {
  echo "<li>".$tmp['titel']."</li>";
}
Das ganze dann halt rekursiv, ja das brauche ich dann wohl doch, da hat ich mich anfangs doch verschätzt ;-)

PS: Vielleicht ist mein Lösungsansatz zu Deinen Aufgabe etwas zu stark von meiner aktuellen Arbeit geprägt, in der auch eine mehr oder weniger identische Teilaufgabe geforder ist. Die Begriffe sind zwar anders, aber es geht um das selbe Thema. Es geht dabei um einen generischen Client, wobei die einzelnen Informationsquellen (Shortcuts, Links oder wie auch immer) in mehreren Strukturbäumen eingehängt werden können. Der einzige wirkliche Unterschied ist der, daß bei dieser Lösung die 'Ordner' und die 'Shortcuts' in einer Tabelle verwaltet werden. Das erleichert die Sache mit den Positionsnummern doch etwas;-)

Das ist aber auch eine komplizierte Aufgabe, vor allem jetzt das ermitteln ob es Unterkategorien oder Produkte gibt, denn das hat Einfluss auf die verfügbaren Aktionen der HTML-Oberfläche(wenn es Unterkategorien gibt kann man nicht löschen, keine Produkte anlegen...)

Viele Grüße
Andreas