Kopie eines mails das ich an stefan zur erörterung dieser frage geschrieben habe:
was ist ein datensatz?
diese frage ist nicht so einfach.
In unserem Datenbanksystem/Backendsystem haben wir hier sehr strenge Kriterien, was vor- und nachteile hat.
Prinzipiell ist das was wir als Datenbank bezeichnen, einfach eine tabelle (und wird technisch auch table genannt)
bei einer tabelle gibt es zeilen und spalten. Wir gehen hier davon unbeirrbar davon aus, dass die anzahl der zeilen variabel ist, die anzahl der spalten aber fest. Die Zeilen entsprechen dann den Datensätzen und die Spalten einer Zeile den Feldern.
also zB die datenbank der univ. forschungsarbeiten
| name | titel | arbeit_als_pdf | |
|---|---|---|---|
| arbeit1 | peter | arbeit | arbeit.pdf |
| arbeit2 | stefan | essen | essen.pdf |
| arbeit3 | max | musik | musik.pdf |
| arbeit4 | usw.usf | ||
die statistikdatenbank hat über 300 spalten und diese spalten werden in der eingabemaske selbst auch wieder als tabelle dargestellt. aber in der grundstruktur sind die felder eindimensional. Es gibt x Felder/Spalten pro Datensatz/Zeile
Es kann mehrere Tabellen geben, die zusammenhängen. Dazu hat jede Tabelle eine ID-Spalte, so dass jeder zeile/jedem datensatz eine eindeutige id zugewiesen ist. Eine andere Tabelle hat dann ein Feld in dem man diese id schreiben kann und somit ist ein eindeutiger zusammenhang hergestellt.
Auf dieses Schema müssen wir alle unsere datenbanken und strukturen hinbiegen. Das schema ist eine technische vorgabe, die jedoch das arbeiten extremst erleichtert. Vor allem das Verwalten von grossen Datenmengen ist mit diesem Schema sehr vorteilhaft. (Wiki und zB Zope haben andere Grundstrukturen und das ist sicher etwas, das wir bei einem nexten projekt viel stärker denken müssen - hier werden aber die techn. voraussetzungen erst langsam durch neue softwareprojekte geschaffen)
nochmals: diese struktur ist eine, auf die wir uns zu projektbeginn geeinigt haben (da waren sich archiv und ich einer meinung) und nicht eine gottgegebene logik. (ausser das ich und archiv natürlich jeweils gott sind :)
dein ursprüngliches konzept ist mit diesem schema nicht kompatibel, weil die anzahl der felder pro datensatz extrem stark variiert. (mein backendsystem kann in einem sehr beschränkten ausmass mit sich änderende r feldanzahl umgehen - zB personen in der strukturdatenbank, aber nicht in dem ausmass wie du das vorgeschlagen hast, wo sich die änderungen über zwei ebenen ziehen)