nicht angemeldet
Hi,
eine hierachie stellt man oft über eine rekursive tabelle da, wobei man rekursionen eigentlich vermeiden sollte. trotzdem wird es oft angewendet.
id | Verzeichnisname | sortierung | übergeordnete_verzechnis_id
dann brauchst du nur eine tabelle und die tabellenstruktur ist unabhängig davon, wieviele unterverzecihnisse du hast. root verzecihnisee besitzen eben kein übergeordnetets_verzeichnis_id, dessen spalteninhalte sind also NULL und lassen sich somit leicht abfragen. über die spalte sortierung kannst die themen der gleichen ebene beliebig sortieren. aber nicht vergessen, rekursionen sind mit vorsicht zu verwenden.
Jow, die Idee mit rekursiven Tabs ist auch gut. Aber so wie's aussieht werde ich an der bisherigen DB struktur festhalten
idx
idx subject
content
idx id jubject body ... author indate outdate ...
Den Content aus solch einer DB rauszuholen, übersichtlich zu browsen, mit Volltextsuche - das geht einwandfrei.
Ein bischen "Geficke" gibts mit dem "Manage-Content" beim Ermitteln der nächsthöheren idx.idx weil string Variablen like 10.1.1.1 - aber das hab ich auch schon soweit fertig.
Es ist ja auch keine Schande, denke ich, mal eben eine vielleicht 100 oder 500 zeilige 2-spaltige Tabelle komplett auf einen hash zu lesen, zumal das Management-Script sowieso nur von Wenigen und auch nich sooft wie das öffentliche Frontend aufgerufen wird.
Und Inhaltsverzeichnisse, bzw, Hierarchie's für Dokumentenablagen mit mehr als 500 Zeilen sind eh fragwürdig bzw. eines reDesigns wert. Heißt: evntl. Gedanken zu einer übergeordneten Kategorie, sog. Bereiche...
Später Gruss,
Rolf-Erwin
SELFforum - Das Tor zur Welt!
Theoretiker: Wie kommt das Kupfer in die Leitung?
Praktiker: Wie kommt der Strom in die Leitung?