[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

[mkinzler]

Zitat:

- Parent speichern ==> da isses relativ schwer die Baumstruktur zu kriegen, weil man ja bei den Blättern anfangen müsste

???
Man muss bei der Wurzel anfangen. Sonst gibt es die Parents ja noch nicht!

[r2c2]

Zitat:

Zitat von mkinzler

Zitat:

- Parent speichern ==> da isses relativ schwer die Baumstruktur zu kriegen, weil man ja bei den Blättern anfangen müsste

???
Man muss bei der Wurzel anfangen. Sonst gibt es die Parents ja noch nicht!

Und woher weißt du, was die Wurzel ist? Wenn die einzige Info jeweils n Verweis auf sein Parent ist, kann sogar ein Graph rauskommen, der "mehrere Wurzeln" hat, also gar kein Baum mehr ist. Die einzige Möglichkeit, die mir in so nem Fall einfällt ist, alles auslesen(muss, wenn man den ganzen Baum darstellen will eh machen), alle nacheinander durchgehen und aneinanderhängen. Das, was letztendlich keinen Verweis auf n Parent-Knoten hat, ist die Wurzel(oder die Wurzeln).

Oder wo liegt mein Denkfehler?

mfg

Christian

[hoika]

Hallo,

es kann ja mehrere Wurzeln (Haupt-Kategorien) geben,
das sind die mit Parent=0.

Wenn ich so einen Baum komplett füllen müßte,
würde ich mir eine rekursive SP schreiben,
begonnen wird bei Parent=0.


Heiko

[DeddyH]

Dieser Thread könnte u.U. interessant sein.

[r2c2]

Zitat:

Zitat von hoika

es kann ja mehrere Wurzeln (Haupt-Kategorien) geben,
das sind die mit Parent=0.

das is klar.

Zitat:

Wenn ich so einen Baum komplett füllen müßte,
würde ich mir eine rekursive SP schreiben,
begonnen wird bei Parent=0.

Und schon sind wir bei dem, was ich (noch) nicht kann. Bisher noch nie Stored Procedures(ich nehm mal an die meinst du mit 'SP') geschieben. Werd ich mir vllt. aber mal angucken...

Aber mal anders:
Is der Anstz mit der Children-Liste nicht ebenso gut, aber einfacher zu realisieren? Gibt es Nachteile, die im in Moment nicht sehe?

mfg

Christian

[mkinzler]

Man kann eine virtuelle Wurzel einfügen.
es gibt auc DBMS, welche Funktionen für rekursive Strukturen können.

[shmia]

Zitat:

Zitat von rayj

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.

Da würde sich ein Wiki anbieten.
Über das Kategorien System kann man die Artikel bauartig organisieren.
Alle Benutzer eurer Firma haben über Intranet einen lesezugriff; die 4 IT-ler dürfen auch schreiben.

[hoika]

Hallo,

der Änderungsaufwand ist mit einem Parent-Feld geringer.
Das Verschieben eines Eintrages z.B. einer Hauptkategorie
ein Level tiefer wird einfach durch Setzen des Parent dieser Hauptkategorie erreicht.


Heiko