Hallo,
die Überschrift ist vielleicht etwas irreführend. Das bitte ich zu entschuldigen. Es geht um folgendes:
Ich bin dabei eine Verwaltungssoftware für Museumsbestände zu schreiben. Jetzt hat ein Museum welches Bücher katalogisieren will andere Einträge als ein Museum welches Kronkorken archiviert (soll nur als Beispiel dienen )
Nun sind mir 2 Möglichkeiten eingefallen, wie man das lösen kann.
1. Eine Tabelle für jede "Museumsart".
Das hat den Vorteil, dass man relativ einfach eine spezialisierte Anfrage stellen kann (Bsp: "titel = 'su und so' AND nummer > 20"). Ein großer Nachteil ist allerdings, dass man diese Art nur relativ schwer erweitern kann (Tabelle erweitern/ändern, Programm anpassen). Zudem kommt für jede "Museumsart" eine neue Tabelle hinzu.
2. Alle Werte eines Eintrags als Key-Value-Pair speichern. Also eine Tabelle der folgenden Art [eintrag_id, key, value].
Vorteil ist, dass man für ein neues Attribut nur ein neuen Key einfügen muss (die GUI könnte ja dynamisch erzeugt werden). Auch eine Suchanfrage eines Wortes in mehreren Attributen ist so einfacher.
Nachteile sind allerdings, dass nur ein Datentyp verwendet werden kann und dass spezialisierte Suchanfragen nicht mit SQL (zumindest habe ich noch keine Idee) realisiert werden können.
2.1 Das Problem mit den unterschiedlichen Datentypen könnte man vielleicht durch mehrere 'element_data' Tabellen lösen.
So, lange Rede, wenig Sinn. Kommen wir nun zu meiner Frage: Welche der Herangehensweisen ist sinnvoll? (Ich tendiere momentan zu 2.1) Habt ihr noch andere Lösungsideen?
PS: Die Beispiele dienen nur zur Veranschaulichung. Implementiert werden soll das später mindestens für MySQL, MS-SQL und PostgreSQL.
die Überschrift ist vielleicht etwas irreführend. Das bitte ich zu entschuldigen. Es geht um folgendes:
Ich bin dabei eine Verwaltungssoftware für Museumsbestände zu schreiben. Jetzt hat ein Museum welches Bücher katalogisieren will andere Einträge als ein Museum welches Kronkorken archiviert (soll nur als Beispiel dienen )
Nun sind mir 2 Möglichkeiten eingefallen, wie man das lösen kann.
1. Eine Tabelle für jede "Museumsart".
Das hat den Vorteil, dass man relativ einfach eine spezialisierte Anfrage stellen kann (Bsp: "titel = 'su und so' AND nummer > 20"). Ein großer Nachteil ist allerdings, dass man diese Art nur relativ schwer erweitern kann (Tabelle erweitern/ändern, Programm anpassen). Zudem kommt für jede "Museumsart" eine neue Tabelle hinzu.
Code:
CREATE TABLE elements_for_museum_1 (
`id` int(11) NOT NULL AUTO_INCREMENT,
`groupID` int(11) DEFAULT '0',
`number` int(10) DEFAULT NULL,
`title` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
);
2. Alle Werte eines Eintrags als Key-Value-Pair speichern. Also eine Tabelle der folgenden Art [eintrag_id, key, value].
Vorteil ist, dass man für ein neues Attribut nur ein neuen Key einfügen muss (die GUI könnte ja dynamisch erzeugt werden). Auch eine Suchanfrage eines Wortes in mehreren Attributen ist so einfacher.
Nachteile sind allerdings, dass nur ein Datentyp verwendet werden kann und dass spezialisierte Suchanfragen nicht mit SQL (zumindest habe ich noch keine Idee) realisiert werden können.
Code:
CREATE TABLE `element_data` (
`element_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`key` varchar(255) DEFAULT NULL,
`value` varchar(255) DEFAULT NULL,
PRIMARY KEY (`element_id`)
);
2.1 Das Problem mit den unterschiedlichen Datentypen könnte man vielleicht durch mehrere 'element_data' Tabellen lösen.
Code:
CREATE TABLE `element_data_char` (
`element_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`key` VARCHAR(255) DEFAULT NULL,
`value` VARCHAR(255) DEFAULT NULL,
PRIMARY KEY (`element_id`)
);
CREATE TABLE `element_data_int` (
`element_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`key` VARCHAR(255) DEFAULT NULL,
`value` INTEGER(10) DEFAULT NULL,
PRIMARY KEY (`element_id`)
);
So, lange Rede, wenig Sinn. Kommen wir nun zu meiner Frage: Welche der Herangehensweisen ist sinnvoll? (Ich tendiere momentan zu 2.1) Habt ihr noch andere Lösungsideen?
PS: Die Beispiele dienen nur zur Veranschaulichung. Implementiert werden soll das später mindestens für MySQL, MS-SQL und PostgreSQL.
Zuletzt bearbeitet: