[Tabellendesign] Mehrstufige Unterkategorien

[rayj]

Hallo
Ich hätte eine Datenbank-technische Frage und zwar:
Ich muss ein Programm schreiben, in welchem Fragen/Probleme und Antworten/Dokumente etc. dazu gespeichert werden können.

Es soll vor allem in unserer IT-Abteilung benutzt werden, da wir nur 4 Leute sind und so meist alle an etwas anderem arbeiten und viele Probleme öfters auftauchen und dann nur einer bescheid weiss.

Es sollen Kategorien und mehrere Stufen an Unterkategorien angelegt werden können, doch genau da häng ich fest.

Angenommen es soll so aussehen:

IT
--Programmierung
----Delphi
----PHP
----C#
--Hardware
--Software
----Windows Xp
--Sonstiges

Dann mach ich ja ne Tabelle namens Kategorien, nur da weiss ich nicht wie ich es anstellen soll, dass ich einer Kategorie eine Unterkategorie angeben kann und dann in Delphi herausfinden kann, auf welchem Level sich die Kategorie befindet.

Ich hoffe ihr versteht die Frage. Wäre um einen Denkanstoss sehr dankbar.

[DeddyH]

Ich glaube, was Du suchst, sind Nested Sets

[mkinzler]

Einfach Tabelle eine Feld erweitern, das die ID des Vorgängers enthält. man könnte auch den Level mit ablegen, wäre aber gefährlich, wenn die Kategorie verschoben oder das Schema weiter aufgedrösselt wird.

[hoika]

Hallo,

oder um es kurz zu machen.

Deine Kategorie-Tabelle enthält

Id Integer
PreId Integer
Name Char

PreId ist entweder 0, für Hauptkategorie
oder >0, dann ist es eine Subkategorie und PreId zeigt auf die eltern-Kategorie.

Ich würde noch eine Dummy-Kategorie Id=0, PreId=0 anlegen
und dann auf PreId einen ForeignKey auf Id setzen.


Heiko

[Codewalker]

Ich habe da in meinem alten Projekt ein ähnliches Problem gehabt und es auf andere Art gelöst (entspricht aber definitiv nicht einer Normalform ;-) ): Das Feld Kategorie enthielt einen beliebigen Pfad. Unterordner wurden durch \ getrennt. Mit einer kleinen Funktion konnte ich mir alle Datensätze in einem Treeview als Baum darstellen lassen. Den "Pfad" konnte man schön zerlegen und so auch ohne weiteres die Tiefe bestimmen. Die Funktion ist allgemein geschrieben, ich habe sie nicht zu Hand, wenn aber Interesse besteht, suche ich sie morgen mal raus.

[mkinzler]

Aber warum sollte man Funktionalitäten des DBMS verschmähen und alles selber umständlich lösen? :gruebel:

[Codewalker]

Naja, ich brauchte so nur 2 Funktionen. Eine baut mir den Baum auf, die andere liefert mir alle Kategorien unter einer Oberkategorie zurück. War mir deutlich(!) weniger Aufwand als mit SQLs und Nested Sets zu arbeiten, und daher gar nicht umständlich. Kommt aber natürlich auf das Projekt an und was man damit machen will

[mkinzler]

Und was macht man, wenn nun eine Kategorie geändert, verschoben wird oder das Schema feiner strukturiert wird?
Außerdem finde ich diese Vorgehensweise nicht wirklich einfacher.

[raiguen]

Zitat:

Zitat von raji

Ich muss ein Programm schreiben, in welchem Fragen/Probleme und Antworten/Dokumente etc. dazu gespeichert werden können.

Ähn...Frage: warum sich die Arbeit/Mühe machen, sowas selber zuschreiben, wenn es schon was fertiges gibt ->ScribblePapers oder CueCards
Mit dem ersteren organisiere ich alle meine Codeschnippsel, Tipps&Tricks und Sonstiges zu meinen Projekten - feine Sache

[r2c2]

Hab momentan ähnliche Überlegungen. 4 Möglichkeiten hab ich dabei in Erwägung gezogen:

- nested sets ==> is wegen höherer Komplexität beim Ändern der Baumstruktur rausgefallen
- den Pfad als string(bzw. varchar) speichern ==> Ändern der Baumstruktur is da noch ekliger
- Parent speichern ==> da isses relativ schwer die Baumstruktur zu kriegen, weil man ja bei den Blättern anfangen müsste
- die IDs der Children als varchar hinterlegen

Für letzteres hab ich mich entschieden(außer ich find doch noch was besseres ;-)). Das ist relativ einfach, man kriegt die Baumstruktur leicht, das Verändern des Baums macht auch keine Probleme. Nur beim Entfernen von Knoten is der Aufwand relativ groß, weil alle Einträge durchgegangen werden müssen um eventuelle inkonsistenzen zu vermeiden.

mfg

Christian