Reihenfolge von verschiebbaren Kapiteln

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo Leute,

ich möchte eine Datenbank machen, die Kapitel und Unterkapitel für eine Webanwendung enthält.

Meine Schwierigkeit ist jetzt, dass ich die Reihenfolge der Kapitel und der Unterkapitel noch nicht kenne.

Wie könnte ich denn das elegant lösen, dass man später die Reihenfolge verändern kann und diese in die Datenbank gespeichert wird.

Dachte mir das so:

tabelle Inhalt
ID | Beschriftung | Hirarchieebene
1 | Figuren | 1
2 | Einleitung | 1
3 | Frodo | 2
4 | Samweis | 2
5 | Gandalf | 2

tabelle Reihenfolge
ID | Inhalt\_ID
1 | 2
2 | 1
3 | 3
4 | 5
5 | 4

würde die Ausgabe ergeben:

  1. Einleitung
  2. Figuren
    2.1 Frodo
    2.2 Gandalf
    2.3 Samweis

Ist aber eben nicht sehr elegant, weil ja dann jedesmal die ganze Tabelle „Reihenfolge“ geändert werden muss, wenn sich was an der Reihenfolge ändert.

Habt ihr ne Idee?

der Günther

#2

Hallo Günther!

Wie könnte ich denn das elegant lösen, dass man später die
Reihenfolge verändern kann und diese in die Datenbank
gespeichert wird.

Schnellschuss:

tabelle Inhalt
ID | Beschriftung | Ebene | Sortierung | Parent
1 | Figuren | 1 | 200 | 
2 | Einleitung | 1 | 100 | 
3 | Hobbits | 2 | 100 | 1
4 | Frodo | 3 | 100 | 3
5 | Samweis | 3 | 200 | 3
6 | Gandalf | 2 | 200 | 1

ergibt:

Einleitung
Figuren
 Hobbits
 Frodo
 Samweis
 Gandalf

Damit solltest du nach Belieben verschieben, einfügen, Ebenen dazwischenziehen und Ebenen löschen können. In dieser Struktur kannst du die Richtigkeit der Daten auch noch ganz nett mit constraints absichern (unique key auf ebene/sortierung, foreign key von parent auf Id).
Bei den Abfragen ist das dann natürlich nicht mehr ganz so trivial, ausser dein RDBMS unterstützt (wie z.B. Oracle) hierarchische Selects oder du arbeitest überhaupt prozedural.

Gruß
Martin

#3

Tschau günther
In einer db sollten eigendlich werte die einmal vergeben wurden nicht mehr geändert werden. Damit ich in meiner db sachen ändern kann, habe ich folgendes gemacht:
Felder:
NRVRN00 SAREC00
00001 7
00002 7
…
9998 7
9999 2
NRVRN00 mit 9999 und dem SAREC00 2 ist immer der aktuelle, der NRVRN00 mit dem SAREC00 = 7 ist saldiert geändert oder gelöscht.
Einen domänencode sollte auch nie verändert werden (beweispflicht):
also:
feldeintrag 1 sollte immer figuren sein und feld 2 immer einleitung.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo and,

In einer db sollten eigendlich werte die einmal vergeben
wurden nicht mehr geändert werden.
Damit ich in meiner db
sachen ändern kann, habe ich folgendes gemacht:
Felder:
NRVRN00 SAREC00
00001 7
00002 7
…
9998 7
9999 2
NRVRN00 mit 9999 und dem SAREC00 2 ist immer der aktuelle, der
NRVRN00 mit dem SAREC00 = 7 ist saldiert geändert oder
gelöscht.

Wovon du hier vermutlich sprichst nennt sich Historienführung. Ziemlich wichtig für Finanzbuchhaltungen. Es geht hier aber um die Menüstruktur einer HP, nicht um die Eingangsrechnungen von Enron…

Einen domänencode sollte auch nie verändert werden
(beweispflicht):

Du meinst alle HPs müssen statisch sein? Von welcher Beweispflicht sprichst du?

also:
feldeintrag 1 sollte immer figuren sein und feld 2 immer
einleitung.

Warum?

Gruß
Martin

#5

Hallo martin,

In einer db sollten eigendlich werte die einmal vergeben
wurden nicht mehr geändert werden.
Damit ich in meiner db
sachen ändern kann, habe ich folgendes gemacht:
Felder:
NRVRN00 SAREC00
00001 7
00002 7
…
9998 7
9999 2
NRVRN00 mit 9999 und dem SAREC00 2 ist immer der aktuelle, der
NRVRN00 mit dem SAREC00 = 7 ist saldiert geändert oder
gelöscht.

Wovon du hier vermutlich sprichst nennt sich Historienführung.
Ziemlich wichtig für Finanzbuchhaltungen. Es geht hier aber um
die Menüstruktur einer HP, nicht um die Eingangsrechnungen von
Enron…

///Ich arbeite in einer bank und bin natürlich davon ausgegangen. Mir ist klar dass eine hp so etwas
///nicht braucht. Aber auch auf meiner privaten hp, schaue ich drauf.

Einen domänencode sollte auch nie verändert werden
(beweispflicht):

Du meinst alle HPs müssen statisch sein? Von welcher
Beweispflicht sprichst du?

///Eben bankverseuchte antwort. Ein bsp. wenn der code 1234 banklagend ist, muss der code 1234 ever
///banklagernd sein.

also:
feldeintrag 1 sollte immer figuren sein und feld 2 immer
einleitung.

Warum?

///Wieder, eben banverseucht. Wenn ich z.b. einen eintrag 1000 blablabal auf 1000 blablabla ändere, muss ich
///einen historie-eintrag machen, damit man in 100 jahren noch nachvollziehen kann, was ich ab 23.03.2006 um
///16:13:33:00213241 gemacht habe.

Gruß and