nicht angemeldet
Daten-Strukturierung mit vielen Beziehungen / Mehrsprachigkeit
Hallo Forum,
Ich versuche im Moment eine bestehende Datenstruktur optimal neu zu erstellen. Als Ausgangslage mal ein Auszug der bestehenden Entities:
+--------------------+ +--------------------+ +--------------------+
| Medienmitteilungen | | Bücher | | Autoren |
+--------------------+ +--------------------+ +--------------------+
| ID | | ID | | ID |
| Title | | Title | | Vorname |
| etc ... [1] | | etc ... [1] | | Name |
| isDeleted | | isDeleted | | etc ... [1] |
| etc ... [2] | | etc ... [2] | | isDeleted |
+--------------------+ +--------------------+ | etc ... [2] |
+--------------------+
~~~[1] Jedes Entity hat eine unterschiedliche Anzahl Properties (Spalten), bei Büchern sind dies zum Beispiel noch die ISBN-Nummer (varchar), das Erscheinungsdatum (datetime) ..., bei den Autoren kommen noch Geburtsdatum (datetime), Wohnort (varchar) usw. vor.
[2] Jedes Entity hat "interne" Felder. Diese Felder kommen überall vor. Es sind dies: isDeleted, dteDeleted, hasDeletedAdminUserId etc... Ich werde sie weiter unten <adminProps> nennen.
Zwei Bedingungen müssen nun erfüllt werden:
- Das ganze muss mehrsprachig sein, wobei Title zum beispiel sprachabhängig ist, das Geburtsdatum wiederum nicht.
- Die Entities müssen beliebig untereinander verknüpft werden können: Autoren schreiben Medienmitteilungen, Medienmitteilungen werden zu Büchern herausgegeben, Autoren schreiben Bücher, Autoren schreiben Referate, Referate werden an Workshops vorgelesen, zu Workshops entstehen Medienmitteilungen, das Resultat eines Workshops kann wiederum ein Buch sein. Also beliebig ist nicht untertrieben :-)
Mein Ansatz ist nun der Folgende:
Alle Entities werden in einer Tabelle verwaltet und erhalten eine "interne" Bezeichnung:~~~db
+--------------------+
| Entities |
+--------------------+
| ID | Desc |
| 1 | 'media' |
| 2 | 'book' |
| 3 | 'author' |
| 4 | 'workshop' |
| ... | ... |
+--------------------+
Primary: ID
Dazu kommt eine Tabelle in der die Elemente den Entities zugewiesen werden, gleichzeitig werden dort auch die <adminProps> verwaltet:~~~db
+------------------------------------------+
| Elements |
+------------------------------------------+
| ElementID | EntityId | <adminProps> |
| 1 | 1 | 1,#12.12.06#, ... |
| 2 | 1 | 1,#14.12.06#, ... |
| 3 | 4 | 1,#14.12.06#, ... |
| 4 | 3 | 1,#15.12.06#, ... |
| 5 | 3 | 1,#15.12.06#, ... |
| 6 | 2 | 1,#17.12.06#, ... |
| 7 | 1 | 1,#24.12.06#, ... |
| ... | ... | ... |
+------------------------------------------+
Primary: ElementID + EntityID
Die Elemente können nun untereinander folgendermassen in Beziehung gebracht werden:~~~db
+--------------------+
| Hierarchie |
+--------------------+
| ParentID | ChildID |
| 1 | 4 |
| 1 | 5 |
| 3 | 1 |
| 3 | 7 |
| 3 | 4 |
| 3 | 5 |
| 6 | 2 |
| 3 | 6 |
| ... | ... |
+--------------------+
Primary: ParentID + ChildID
~~~ will heissen "Zur Medienmitteilung 1 gehören die Autoren 4 und 5 <haben erfasst>", "Zum Workshop 3 gab es die Medienmitteilungen 1 und 7 <wurde publiziert>", "Am Workshop 3 haben die Autoren 4 und 5 teilgenommen <Referat gehalten>", "Zum Buch 6 gab es eine Medienmitteilungen 2 <wurde publiziert>", "Aus dem Workshop 3 ist das Buch 6 entstanden <wurde geschrieben>", ...
Ich kann somit die verschiedenen Elemente beliebig untereinander in Beziehung bringen.
Bis jetzt wurde die Sprache aussen vor gelassen, bis jetzt war sie auch noch nicht relevant. Nun kommen die verschiedenen Elementattribute ins Spiel, sie müssen nicht zwingen sprachabhängig sein. Die Sprachen werden in einer eigenen Tabelle mit ihrem ISO-Code gespeichert:~~~db
+--------------------+
| Sprachen |
+--------------------+
| ISO | Desc |
| 'de' | 'german' |
| 'en' | 'english' |
+--------------------+
Primary: ISO
~~~es sind zur Zeit diese zwei Sprachen vorhanden. Weitere Sprachen könnten aber in Kürze dazukommen.
Wie gesagt, die Elementattribute sind nicht für jede Entity gleich (siehe Beispiel ganz oben). Ein Ansatz, den ich mir nun überlegt habe ist der folgende. Alle Elementeattribute werden in einer Tabelle abgebildet und einem Element sprachabhängig zugewiesen:~~~db
+--------------------------------------------------------------------------------------+
| Attributes |
+--------------------------------------------------------------------------------------+
| ElementID | ISO | title | firstname | lastname | etc ... |
| 1 | 'de' | 'Springböcke' | NULL | NULL | #xx#, 'xx', x, ... |
| 1 | 'en' | 'Springbocks' | NULL | NULL | #yy#, 'yy', y, ... |
| 3 | 'de' | 'Abwasch' | NULL | NULL | #zz#, 'zz', z, ... |
| 4 | 'de' | 'Dr.' | 'Hansi' | 'Muster' | #vv#, 'vv', v, ... |
| 4 | 'en' | 'Dr.' | 'Hansi' | 'Muster' | #vv#, 'ww', w, ... |
| 6 | 'de' | 'Harry Potter' | NULL | NULL | #kk#, 'kk', k, ... |
| 6 | 'en' | 'Harry Potter' | NULL | NULL | #kk#, 'ff', k, ... |
+--------------------------------------------------------------------------------------+
Primary: ElementID + ISO
~~~alle Elemente werden sprachabhängig in einer Tabelle zusammengefasst. kommt bei irgendeinem Element ein neues Attribute hinzu, und ist es noch nicht in dieser Tabelle vorhanden, muss es als neue Spalte hinzugefügt werden.
Eine Idee wäre noch einen generischen Sprachcode einzuführen würd sprachunabhängige Attribute wie ein Datum oder ein Geschlecht oder Vor- Nachname etc.
Ok langer Rede kurzer Sinn. Seht ihr diesen Ansatz als vernünftig an oder würdet ihr das ganze anderes lösen? Ich bin für jeden Hinweis dankbar. Vielleicht habt ihr ja schon sowas ähnliches gemacht oder braucht auch eine ähnliche Datenstruktur (ob das jetzt Medienmitteilungen oder Gästebucheinträge oder Aktivitäten sind, ist ja eigentlich egal), dann lasst uns zusammen "das Hirn stürmen".
Grüsse
Siramon,
ja der Penner aus Nr. 14
-
Alle Entities werden in einer Tabelle verwaltet und erhalten eine "interne" Bezeichnung:
+--------------------+
| Entities |
+--------------------+
| ID | Desc |
| 1 | 'media' |
| 2 | 'book' |
| 3 | 'author' |
| 4 | 'workshop' |
| ... | ... |
+--------------------+
Primary: IDGrauenhaft. Das ist ein Versuch das RDBMS zu umgehen oder anders formuliert, dass macht das RDBMS schon. Ist aber ein recht populärer Ansatz (hier;).
Wie gesagt, die Elementattribute sind nicht für jede Entity gleich (siehe Beispiel ganz oben).
Aha. Sonst wären es wohl auch keine Entitäten, oder? ;)
Ein Ansatz, den ich mir nun überlegt habe ist der folgende. Alle Elementeattribute werden in einer Tabelle abgebildet und einem Element sprachabhängig zugewiesen:
*BRRR*
Ok langer Rede kurzer Sinn. Seht ihr diesen Ansatz als vernünftig an oder würdet ihr das ganze anderes lösen? Ich bin für jeden Hinweis dankbar. Vielleicht habt ihr ja schon sowas ähnliches gemacht oder braucht auch eine ähnliche Datenstruktur (ob das jetzt Medienmitteilungen oder Gästebucheinträge oder Aktivitäten sind, ist ja eigentlich egal), dann lasst uns zusammen "das Hirn stürmen".
Der Ansatz ist vernünftig, ein schönes Beispiel dafür, dass auch kohärente Überlegungen falsch sein können. Erinnert uns fast an die Gläubigen von Marx und so, die mach(t)en eigentlich auch keine Fehler. Funzt halt nur net.
Also, mal ein wenig brainstorming:
Ein an und für sich eher simples Datenmodell ("Medienmitteilungen", "Bücher", "Autoren", "Nutzer"(?)) soll aufgebohrt werden, da Mehrsprachigkeit angefordert ist. Hmm, was würde King Lully da erwarten?Eigentlich doch, dass Strings aus extrahiert werden und in eine Tabelle abgelegt werden. Also in der Tabelle "Bücher" bspw. würde das Attribut "Titel" auf einmal durch ein trockenes "69" ersetzt werden. Mit diesem Zeiger holt man sich dann aus der Tabelle "Wörter" unter Angabe der Sprache den Titel.
Dazu sind natürlich auch bestimmte Einstellungen auf die Datenbasis erforderlich, wir wollen ja auch sicherstellen, dass die Wortliste vollständig ist. Da das RDBMS nicht namentlich benannte worden ist, müsste dsbzgl. leider geraten werden.
Jetzt schreibst Du noch irgendwo sowas: "Die Entities müssen beliebig untereinander verknüpft werden können: Autoren schreiben Medienmitteilungen, Medienmitteilungen werden zu Büchern herausgegeben, Autoren schreiben Bücher, Autoren schreiben Referate, Referate werden an Workshops vorgelesen, zu Workshops entstehen Medienmitteilungen, das Resultat eines Workshops kann wiederum ein Buch sein. Also beliebig ist nicht untertrieben"
Hmm, Dir ist schon klar, dass Du gegen die Regel Nr. 1 verstösst?
Wir haben also die Anforderung "Multi-Kulti" und die Anforderung X. Wollen wir mal die Anforderung X ein wenig beleuchten.
Ist die anzustrebende Struktur sehr heterogen? => kein RDBMS verwenden
Welche Entitäten ändern sich genau wie? => einzelfallprüfen, ob die o.g. Entitäten überhaupt die Geschäftslogik genau treffenWir schlagen vor das oben beschriebene Entitäten-Gemisch mal ein wenig aufzulösen und nicht zu karikieren, wir müssen genau die Verzeigerung ("1:n", "n:m", "1:1" ;) erkennen können.
-
Hallo Ludger,
vielen Dank für deine Antwort, ich werde deine Anmerkungen direkt kommentieren und noch ein paar Infos zusätzlich angeben, vielleicht beteiligen sich dann auch noch ein paar andere an diesem Brainstorming.
Ich habe es bewusst als Brainstorming bezeichnet, weil es für mich klar ist, dass es verschiedene Möglichkeiten gibt abhängig von der Komplexität der Datenstruktur, der Performance, der Erweiterbarkeit von Sprachen oder Attributen. Dazu habe ich verschiedene Threads im Archiv mit den folgenden Stichworten gefunden. Zum Bespiel diesen [1], in dem die Ilja die Kriterien Geschwindigkeit und Erweiterbarkeit beleuchtet.
Oder diesen Thread [2] in dem für jede Sprache jeweils ein Attribut (title_de, title_en) hinzugefügt wird. Dabei wird die Performance gross sein, dafür leidet aber die Erweiterbarkeit. Rouven schlägt darum den auch von dir genannten Ansatz mit einer "Wörtertabelle" vor.
In diesem Thread [3] wird wiederum die gleiche Thematik beleuchtet vor allem geht es dort darum wie weit man Normalisieren soll und darf. Dein Standpunkt dort war ein "sauberes" Design, Performance soll mittels Hardware gewährleistet werden. Auch in [4] diesen [5] Threads [5] schlagen Thomas, Cheatah, Michael und Ilja eine ähnliche Lösung vor.Also über Sprache wurde schon häufig diskutiert, zwei Ansätze:
- für jede Sprache n zusätzliche Attribute (title_de, title_en) mit den Vorteilen der Geschwindigkeit, wenn aber eine weitere Sprache hinzukommt wirds ein Horror [2]
- Textbausteine in einer Sprachetabelle verwalten ("Wörtertabelle") [4/5] mit den Vorteilen, dass beliebig viele Sprachen einfach hinzugefügt werden können, es muss dabei nichts an der Struktur verändert werden. Zwei Nachteile gibt es hier natürlich auch, der eine wurde erwähnt (Performance & Join-Wars), den zweiten erwähne ich an dieser Stelle, vielleicht weiss jemand dazu noch Tipps. Es gibt mehrere Arten von Texttypen in den verschiedenen RDBMS, meistens <text> und <varchar(n)>. Wie soll damit umgegangen werden? Die ganze Wortliste als <text> verwalten? Zwei Spalten mit den Typen <text> und <varchar(200)>, eines jeweils NULL? Zwei verschiedene Wortlisten mit dem jeweiligen Typ? Und schon versuchen wir wieder das RDBMS nachzubauen (Ich zitiere dich mal: "Grauenhaft" *g*).
So, nun aber zu deinen Punkten:
Alle Entities werden in einer Tabelle verwaltet und erhalten eine "interne" Bezeichnung:
+--------------------+
| Entities |
+--------------------+
| ID | Desc |
| 1 | 'media' |
| 2 | 'book' |
| 3 | 'author' |
| 4 | 'workshop' |
| ... | ... |
+--------------------+
Primary: IDGrauenhaft. Das ist ein Versuch das RDBMS zu umgehen oder anders formuliert, dass macht das RDBMS schon. Ist aber ein recht populärer Ansatz (hier;).
[...]
Jetzt schreibst Du noch irgendwo sowas: "Die Entities müssen beliebig untereinander verknüpft werden können: Autoren schreiben Medienmitteilungen, Medienmitteilungen werden zu Büchern herausgegeben, Autoren schreiben Bücher, Autoren schreiben Referate, Referate werden an Workshops vorgelesen, zu Workshops entstehen Medienmitteilungen, das Resultat eines Workshops kann wiederum ein Buch sein. Also beliebig ist nicht untertrieben"
[...]
Ist die anzustrebende Struktur sehr heterogen? => kein RDBMS verwenden
Welche Entitäten ändern sich genau wie? => einzelfallprüfen, ob die o.g. Entitäten überhaupt die Geschäftslogik genau treffenWir schlagen vor das oben beschriebene Entitäten-Gemisch mal ein wenig aufzulösen und nicht zu karikieren, wir müssen genau die Verzeigerung ("1:n", "n:m", "1:1" ;) erkennen können.
Dazu werde ich mal konkret, es gibt folgende Entitäten: Bücher, Konferenzen, Workshops, Referate, Protokolle, Medienmitteilungen und Autoren, dabei gibt es zwei verschiedene Typen von Verknüpfungen: temporale und logische Beziehungen.
Beispiel für eine temporale Beziehung: Aus Konferenzen können Workshops entstehen und danach darüber ein Buch geschrieben werden.
Beispiel für eine logische (?) Beziehung: Autoren verfassen jeweils Bücher oder Medienmitteilungen bzw. halten Reden an Konferenzen (Referate).
Weiteres Beispiel für eine logische (= !temporale *g*) Beziehung: An Konferenzen gibt es Referate, über Workshops Protokolle.Alle Beziehungen sind n:m!
Ziel ist es zum Beispiel bei Büchern in einer Liste die dazugehörigen Elemente aus verschiedenen Entitäten anzugeben. Also Medienmitteilungen, die zum Buch geschrieben wurden, Workshops die zuvor zu diesem Thema durchgeführt wurden etc.
Der klassische Ansatz wäre eine Tabelle für jede Entität, diese werden jeweils über m:n Verknüpfungen in seperaten Tabellen referenziert. Schön normalisiert, aber "en huere Tabellesalat" (wie wir Schweizer zu sagen pflegen *g*) (vergleiche "Join-Salat" bei den Sprachen). Und jedesmal eine neue Tabelle für eine neue Beziehung der Entitäten. Und wenn eine neue Entität hinzukommt (zB. Gedichte (nur ein Beispiel!)) mache ich n+1 neue Tabellen...
Darum mein Ansatz ganz oben und die folgende (erwähnte) Beziehungstabelle:
+--------------------+
| Hierarchie |
+--------------------+
| ParentID | ChildID |
| 1 | 4 |
| 1 | 5 |
| 3 | 1 |
| 3 | 7 |
| 3 | 4 |
| 3 | 5 |
| 6 | 2 |
| 3 | 6 |
| ... | ... |
+--------------------+
Primary: ParentID + ChildIDIch habe eine logische und eine temporale Verknüpfung ausgedrückt durch eine Elternteil-Kind-Paar.
Ein Ansatz, den ich mir nun überlegt habe ist der folgende. Alle Elementeattribute werden in einer Tabelle abgebildet und einem Element sprachabhängig zugewiesen:
*BRRR*
Ok langer Rede kurzer Sinn. Seht ihr diesen Ansatz als vernünftig an oder würdet ihr das ganze anderes lösen? Ich bin für jeden Hinweis dankbar. Vielleicht habt ihr ja schon sowas ähnliches gemacht oder braucht auch eine ähnliche Datenstruktur (ob das jetzt Medienmitteilungen oder Gästebucheinträge oder Aktivitäten sind, ist ja eigentlich egal), dann lasst uns zusammen "das Hirn stürmen".
Der Ansatz ist vernünftig, ein schönes Beispiel dafür, dass auch kohärente Überlegungen falsch sein können. Erinnert uns fast an die Gläubigen von Marx und so, die mach(t)en eigentlich auch keine Fehler. Funzt halt nur net.
Ich glaube, ich habe dich verstanden, danke fürs Kompliment - werde bald in die Kommunikationsabteilung rüberwechseln *g*
Auch hier zwei Ansätze (lassen wir die Sprache mal weg und ausgehend von dem eingangs erwähnten Schema), entweder alle Attribute in eine Tabelle (mit vielen NULLs) oder der Wörterbuch-Ansatz mit einer Attributtabelle, dann habe ich aber wieder das Typen-Problem und einen join-war (bzw. -salat).
Geplant ist die Entitäten in beiden Ansätzen mittels Views wieder herzustellen.Also: Entweder alles normalisieren (viele, viele Tabellen vor allem wegen den Beziehungen) oder irgendeine Mischrechnung, wobei ich diese favorisiere aber die optimale noch nicht gefunden habe.
Nochmals an alle, vielleicht fällt auch Euch etwas dazu ein? Habt ihr schon Erfahrungen mit sowas gemacht, oder habt ihr einfach auch Lust "das Hirn zu stürmen"?
Ach ja: RDBMS ist ein Microsoft SQL-Server 2003.
Grüsse
Siramon,
ja der Penner aus Nr. 14-
vielen Dank für deine Antwort,
Du hast ja den rechtschreibfehlerlastigen und etwas flapsigen Beitrag mit Humor (zumindest genommen, wir haben noch nicht viel weiter gelesen ;) ausgehalten.
In diesem Thread [3] wird wiederum die gleiche Thematik beleuchtet vor allem geht es dort darum wie weit man Normalisieren soll und darf.
Ganz wichtig ist bei der Sache mit der Normalisierung, dass man _nicht_ prinzipienfest bleibt.
Dein Standpunkt dort war ein "sauberes" Design, Performance soll mittels Hardware gewährleistet werden.
Wenn Du kein Grosssystem entwickelst, wovon wir ausgehen, dann lass mal Performanceüberlegungen aussen vor. Vermutlich kriegst Du doch nicht mehr als eine Transaktion/Sekunde.
Also über Sprache wurde schon häufig diskutiert, zwei Ansätze:
- für jede Sprache n zusätzliche Attribute (title_de, title_en) mit den Vorteilen der Geschwindigkeit, wenn aber eine weitere Sprache hinzukommt wirds ein Horror [2]
Nicht gut.
- Textbausteine in einer Sprachetabelle verwalten ("Wörtertabelle") [4/5] mit den Vorteilen, dass beliebig viele Sprachen einfach hinzugefügt werden können, es muss dabei nichts an der Struktur verändert werden. Zwei Nachteile gibt es hier natürlich auch, der eine wurde erwähnt (Performance & Join-Wars),
"JOIN-Wars"? Da kommen manche wieder zu frühe mit Performance-Überlegungen vermutlich.
den zweiten erwähne ich an dieser Stelle, vielleicht weiss jemand dazu noch Tipps. Es gibt mehrere Arten von Texttypen in den verschiedenen RDBMS, meistens <text> und <varchar(n)>. Wie soll damit umgegangen werden? Die ganze Wortliste als <text> verwalten?
Datentyp text ist so zu sagen eine Ergänzung zum RDBMS, da es ei BLOB ist, beisst sich mit der "Seitenphilosophie" und mit anderem, unbedingt sowas wie VARCHAR() oder CHAR() benutzen.
Zwei Spalten mit den Typen <text> und <varchar(200)>, eines jeweils NULL? Zwei verschiedene Wortlisten mit dem jeweiligen Typ? Und schon versuchen wir wieder das RDBMS nachzubauen (Ich zitiere dich mal: "Grauenhaft" *g*).
Geht es bei der Frage jetzt ums Design der "Wörtertabelle"?
Dazu werde ich mal konkret, es gibt folgende Entitäten: Bücher, Konferenzen, Workshops, Referate, Protokolle, Medienmitteilungen und Autoren, dabei gibt es zwei verschiedene Typen von Verknüpfungen: temporale und logische Beziehungen.
Beispiel für eine temporale Beziehung: Aus Konferenzen können Workshops entstehen und danach darüber ein Buch geschrieben werden.Hier ist eine wichtige Frage zu beantworten und zwar bzgl. der Eindeutigkeit der Entitäten. Wenn aus Entität A Entität B wird, so ist zu überlegen ob Entität A Entität B soweit entspricht, das Entität C zu bilden ist. Beispiel: Es gibt Vertragsanfragen und Verträge, aus Vertragsanfragen können Verträge werden, nur eine Entität? (In diesem Fall hiess die Antwort (wie so oft) übrigens: Nein. Merkregel: Auf keinen Fall Entitäten "vermanschen", im Zweifel immer neue Entität bilden.)
Die Transformationen (Aus A wird B) kannst Du mit einer sauberen stored procedure (SP) realisieren, scheue Dich nicht vor relativ viel SQL-Code.Beispiel für eine logische (?) Beziehung: Autoren verfassen jeweils Bücher oder Medienmitteilungen bzw. halten Reden an Konferenzen (Referate).
Du kommst da mit einer Tabelle 'Autoren' und den üblichen foreign keys (FKs), das Attribut heisst z.B. '<Tabellenname>_Owner_ID'.
Weiteres Beispiel für eine logische (= !temporale *g*) Beziehung: An Konferenzen gibt es Referate, über Workshops Protokolle.
Das müsste alles im Rahmen "normaler" Komplexität eines typischen Datendesign sein. Scheue Dich nicht zig FKs einzubauen. Freunde Dich mit etwas komplexeren SQL-Code für SPs an, wähle unbedingt vernünftige Regeln entsprechend Datenfeldnamen, wir nutzen bspw. die Regel "<Tabellenname>_<"eigentlicher Datenfeldname">" für die Datenfeldnamen, Riesenvorteil: DB-weit eindeutige Namen, für FK-Namen die Regel "<Tabellenname>_<"Datenfeldname auf den verwiesen wird">", also bspw. "Bücher_Autoren_ID" für die Autoren ID der Tabelle Bücher. Sehr hilfreich bei den JOINs.
Alle Beziehungen sind n:m!
Nö, glauben wir nicht. Wär die Hölle. (Bei Daten-Historisierung braucht man viele "n:m"s, aber hier?) man Gegenthese: Fast alle sind "1:n" mit folgenden Ausnahmen:
<Liste_unbekannt>Ziel ist es zum Beispiel bei Büchern in einer Liste die dazugehörigen Elemente aus verschiedenen Entitäten anzugeben. Also Medienmitteilungen, die zum Buch geschrieben wurden, Workshops die zuvor zu diesem Thema durchgeführt wurden etc.
Das geht mit JOINs, da ist erst mal nix "n:m".
Der klassische Ansatz wäre eine Tabelle für jede Entität, diese werden jeweils über m:n Verknüpfungen in seperaten Tabellen referenziert. Schön normalisiert, aber "en huere Tabellesalat" (wie wir Schweizer zu sagen pflegen *g*) (vergleiche "Join-Salat" bei den Sprachen). Und jedesmal eine neue Tabelle für eine neue Beziehung der Entitäten. Und wenn eine neue Entität hinzukommt (zB. Gedichte (nur ein Beispiel!)) mache ich n+1 neue Tabellen...
Du hast halt ein anspruchsvolles Tabellendesign, aber sei beruhigt, es gibt DBs mit 100 bis 200 hübsch verzeigerten Tabellen.
Auch hier zwei Ansätze (lassen wir die Sprache mal weg und ausgehend von dem eingangs erwähnten Schema), entweder alle Attribute in eine Tabelle (mit vielen NULLs) oder der Wörterbuch-Ansatz mit einer Attributtabelle, dann habe ich aber wieder das Typen-Problem und einen join-war (bzw. -salat).
Geplant ist die Entitäten in beiden Ansätzen mittels Views wieder herzustellen.Weisst Du für sowas sind RDBMSe nicht ausgelegt, Du wirst Riesenprobleme bei komplexen Abfragen bekommen, nach einiger Zeit wird das System vermutlich kaputtgehen.
Das RDBMS stellt Dir doch bereits so eine hübsche ERM-Sicht z.V. und verwaltet den Mist intern ähnlich wie von Dir angestrebt, jetzt willst Du einen Rückbau des Systems?Also: Entweder alles normalisieren (viele, viele Tabellen vor allem wegen den Beziehungen) oder irgendeine Mischrechnung, wobei ich diese favorisiere aber die optimale noch nicht gefunden habe.
Alles normalisieren bis Tabellenebene, auf Attributebene "intellignet" normalisieren.
Nochmals an alle, vielleicht fällt auch Euch etwas dazu ein? Habt ihr schon Erfahrungen mit sowas gemacht, oder habt ihr einfach auch Lust "das Hirn zu stürmen"?
Ach ja: RDBMS ist ein Microsoft SQL-Server 2003.
MS SQL Server 2005 vermutlich.
-
Hallo Ludger,
once again ...
vielen Dank für deine Antwort,
... :-)
MS SQL Server 2005 vermutlich.
Äh sorry, SQL Server 2003 gibts ned. Es ist ein SQL Server 2000 (8.x) auf Windows Server 2003.
Wenn Du kein Grosssystem entwickelst, wovon wir ausgehen, dann lass mal Performanceüberlegungen aussen vor. Vermutlich kriegst Du doch nicht mehr als eine Transaktion/Sekunde.
Ack, aber der Ansatz soll pragmatisch und nicht dogmatisch sein...
[Viel Brainstorming ...]
Alles normalisieren bis Tabellenebene, auf Attributebene "intellignet" normalisieren.Ok, überzeugt. Die Beziehungen der verschiedenen Elemente habe ich jetzt "klassisch" abgebildet...
Trotzdem habe ich noch ein paar Fragezeichen bei der Abbildung der Sprachen:
[Ansatz 1]
- Textbausteine in einer Sprachetabelle verwalten ("Wörtertabelle") [4/5] [...]
den zweiten erwähne ich an dieser Stelle, vielleicht weiss jemand dazu noch Tipps. Es gibt mehrere Arten von Texttypen in den verschiedenen RDBMS, meistens <text> und <varchar(n)>. Wie soll damit umgegangen werden? Die ganze Wortliste als <text> verwalten?
Datentyp text ist so zu sagen eine Ergänzung zum RDBMS, da es ei BLOB ist, beisst sich mit der "Seitenphilosophie" und mit anderem, unbedingt sowas wie VARCHAR() oder CHAR() benutzen.
Zwei Spalten mit den Typen <text> und <varchar(200)>, eines jeweils NULL? Zwei verschiedene Wortlisten mit dem jeweiligen Typ? Und schon versuchen wir wieder das RDBMS nachzubauen (Ich zitiere dich mal: "Grauenhaft" *g*).
Geht es bei der Frage jetzt ums Design der "Wörtertabelle"?
Ja genau, wenn ich jedes sprachabhängige Attribute in einer Tabelle mit den Spalten <fk_attributType>, <fk_language>, <fk_element>, <value> (Primary: fk_attributType + fk_language + fk_element) verwalte kann ich ja für <value> nur einen Datentyp verweden und weil auch "ganze Texte" in der DB vorkommen wird es wohl der Typ <text> sein. Oder sehe ich das falsch?
[Ansatz 2]
Eine andere Möglichkeit wäre eine 1:n (n = Anzahl Sprachen) Beziehung zu bilden für die sprachrelevanten Attribute, also in etwa so:
[code lang=db]
+--------------+ +---------------+
| event | | eventLangExt |
+--------------+ +---------------+
| ID | | fk_event |
| date | | fk_language |
| subscriptions| | title |
| isLive | | description |
| etc ... | | longDesc |
+--------------+ | etc ... |
Primary (ID) +---------------+
Primary (fk_event + fk_language)Somit hätte ich das Problem der unterschiedlichen Typen nicht, weil title (varchar 200) und description (varchar 1000) und longDesc (text) unterschiedlich abgespeichert werden sollten.
Beim ersten Ansatz gibt es genau eine Tabelle für die Textbausteine (Wörtertabelle), beim zweiten Ansatz muss ich für jede Entität (Events, Publications etc.) eine zweite bilden mit den sprachabhängigen Attributen...
Auch hier bin ich wieder über jede Idee froh :-)
Grüsse
Siramon,
ja der Penner aus Nr. 14-
Wir hoffen erst einmal, dass Du die involvierten Entitäten nun durchschaust und deren Beziehungen. Es gibt nichts übleres als das Datendesign machen zu müssen bei unklarer bzw. dynamischer Anforderungslage. Denn dann wird der Entwickler massiv bestraft.
Viele Kaufleute haben dafür kein Verständnis, was auch damit zusammenhängt, dass sie die von ihnen erdachte Logik unzureichend (ganz sicher unzureichend für Zwecke der IT) verstehen.
Als Entwickler ist man da alternativlos und muss sich unbeliebt machen.Die ganze Wortliste als <text> verwalten?
Alles was geht als VARCHAR(), ansonsten TEXT (Anzahl der BLOBs minimal halten).
[Ansatz 2]
Eine andere Möglichkeit wäre eine 1:n (n = Anzahl Sprachen) Beziehung zu bilden für die sprachrelevanten Attribute, also in etwa so:
[code lang=db]
+--------------+ +---------------+
| event | | eventLangExt |
+--------------+ +---------------+
| ID | | fk_event |
| date | | fk_language |
| subscriptions| | title |
| isLive | | description |
| etc ... | | longDesc |
+--------------+ | etc ... |
Primary (ID) +---------------+
Primary (fk_event + fk_language)Somit hätte ich das Problem der unterschiedlichen Typen nicht, weil title (varchar 200) und description (varchar 1000) und longDesc (text) unterschiedlich abgespeichert werden sollten.
Anmerkung: Es gibt da so eine Obergrenze von 8k pro Datensatz, also vorsichtig und sparsam sein.
Also, Deine Idee mit dem Auslagern von Attributlisten, das ist Murks und wenn Du die Anforderungslage so verstehen musst, dass das erforderlich ist, dann wird es schwer mit einem RDBMS. (Es kann sein, dass hier eine Ausnahme-Ausnahmesituation vorliegt, also dass die Attribute nie Fremdschlüssel sind und nie nach ihnen gesucht wird (in der WHERE bspw.). Aber wir haben da dbzgl. sehr sehr flaues Gefühl.Beim ersten Ansatz gibt es genau eine Tabelle für die Textbausteine (Wörtertabelle), beim zweiten Ansatz muss ich für jede Entität (Events, Publications etc.) eine zweite bilden mit den sprachabhängigen Attributen...
Attribute auslagern ist so zu sagen ein Kapitalverbrechen während das Vermanschen der Entitäten eine Todessünde ist.
Ach so, noch was zum Datenzugriff: Bei diesem komplexen Datendesign empfehlen wir dringend den Einsatz der so genannten stored procedures und zwar je Entität eine CRUD-Gruppe und für die Geschäftslogik (bspw. Transformation Objekt A -> Objekt B) ein weiteres Rudel, ebenso für administrive Zwecke. Präfixe unterstützen hier eine sinnvolle Namensgebung.
Auf keinen Fall T-SQL Code (ausser dem parametriesierten SP-Aufruf) in die server- bzw. clientseitige Darstellungslogik packen, sondern alles nah an der DB, so dass Du das GUI jederzeit abhängen kannst.-
Hallo Forum,
Die ganze Wortliste als <text> verwalten?
Alles was geht als VARCHAR(), ansonsten TEXT (Anzahl der BLOBs minimal halten).Hmm ich habe ja keine Wahl, oder versteh ich das mit der Wortliste falsch?
Folgende Entitäten als Beispiel: Anlässe, Publikationen und der Vollständigkeit die Sprachen. Alle sprachunabhängigen Attribute werden in der jeweiligen Entität abgebildet (Datum, Bit-Felder, etc ...). Alle sprachabhängigen Attribute werden entweder durch Ansatz 1 oder Ansatz 2 (doof laut deiner Aussage) abgebildet. Nur ich kann mir den Ansatz 1 noch nicht wirklich vorstellen? Also hier mal die Entitäten:+--------------+ +---------------+ +-------------------+ | event | | publications | | languages | +--------------+ +---------------+ +------+------------+ | ID | | ID | | ISO | [desc] | | dateStart | | datePub | +------+------------+ | dateEnd | | date | | 'de' | 'german' | | subscriptions| | etc ... | | 'en' | 'english' | | isLive | +---------------+ | 'fr' | 'french' | | etc ... | Primary (int ID) +------+------------+ +--------------+ Primary (char(2) ISO) Primary (int ID)Nun brauchen wir eine Wortliste, es gibt verschiedene "Worttypen":
+-------------------+ | wordTypes | +------+------------+ | ID | [desc] | +------+------------+ | 1 | 'title' | | 2 | 'descrip.' | | 3 | 'longDesc.'| | ... | etc... | +------+------------+ Primary (int ID)Ok und nun alles zusammen für die Anlässe: (schematisch)
+--------------+ | words | +--------------+ | fk_event | | fk_lang | | fk_wordType | | word | +--------------+ Primary (fk_event + fk_lang + fk_wordType)Hmm und jetzt gibts verschiedene "Word-Typen": Titel, Beschreibung, lange Beschreibung, alles unterschiedlich "lang", also varchar(200), varchar(1000) und text. Da müsste ich ja in der Tabelle "words" 3 Spalten für die unterschiedlichen Typen anlegen zB. word_200, word_1000, word_text. Saudoof und sau-unsauber!
Zugleich habe ich jetzt nur wieder eine Tabelle für die Wörter der Anlässe für die Publikationen muss ja jetzt eine zweite Tabelle her mit deren "Wörtern". Oder ich füge in words noch fk_publication hinzu, dabei ist dann entweder fk_event oder fk_publication NULL und ich habe ein Problem mit dem Primary über (fk_event + fk_publication + fk_lang + fk_wordType) weil da nix NULL sein darf.Entweder verstehe ich Bahnhof oder Ansatz 1 gefällt mir besser...
Wiederum: Sachdienliche Hinweise sind sehr erwünscht *g*
Ach so, noch was zum Datenzugriff: Bei diesem komplexen Datendesign empfehlen wir dringend den Einsatz der so genannten stored procedures und zwar je Entität eine CRUD-Gruppe und für die Geschäftslogik (bspw. Transformation Objekt A -> Objekt B) ein weiteres Rudel, ebenso für administrive Zwecke. Präfixe unterstützen hier eine sinnvolle Namensgebung.
Äh ich mache meistens "RMD-Gruppen" (read, manage, delete; wobei manage insert & update verwaltet).
Auf keinen Fall T-SQL Code (ausser dem parametriesierten SP-Aufruf) in die server- bzw. clientseitige Darstellungslogik packen, sondern alles nah an der DB, so dass Du das GUI jederzeit abhängen kannst.
Habe ich schon gesagt das ich SPs liebe? :-)
Grüsse
Siramon,
ja der Penner aus Nr. 14-
[Wortliste]
Haben wir nicht verstanden. Was ist daran schwer?
Bsph. Aufbau:Words
--
Words_ID
Words_Languages_ID
Words_Text (Typ:VARCHAR(x))Aha, vielleicht liegt das Problem an den BLOBs.
Warum nicht noch ein:Words_BLOBs
--
Words_BLOBs_ID
Words_BLOBs_Languages_ID
Words_BLOBs_Text (Typ:TEXT)(fk_event + fk_publication + fk_lang + fk_wordType) weil da nix NULL sein darf.
Regel Nr. 1: Keine zusammengesetzten PKs verwenden.
Ach so, noch was zum Datenzugriff: Bei diesem komplexen Datendesign empfehlen wir dringend den Einsatz der so genannten stored procedures und zwar je Entität eine CRUD-Gruppe und für die Geschäftslogik (bspw. Transformation Objekt A -> Objekt B) ein weiteres Rudel, ebenso für administrive Zwecke. Präfixe unterstützen hier eine sinnvolle Namensgebung.
Äh ich mache meistens "RMD-Gruppen" (read, manage, delete; wobei manage insert & update verwaltet).CRUD ist u.E. besser, da "manage" unklar ist.
Habe ich schon gesagt das ich SPs liebe? :-)
Eine wichtige Voraussetzung für den Datenzugriffsentwickler.
-
Nachtrag, da haben wir ein paar (kleinere ;) Denkfehler gemacht, irgendwie sowas also:
Words
--
Words_ID -- Eindeutigkeit
Words_Code -- zeigt auf das mehrsprachige Attribut
Words_Languages_ID -- zeigt auf die Sprache
Words_VARCHAR (Typ:VARCHAR(x)) -- die Zeichenkette-
Hallo Ludger,
Nachtrag, da haben wir ein paar (kleinere ;) Denkfehler gemacht, irgendwie sowas also:
Naja, dann mach ich jetzt pro Entität (Workshops, Konferenzen, Referate etc.) 3 Words-Tabellen? Einmal varchar(200) einmal varchar(1000) und einmal text und das jeweils für die Entitäten Workshops, Konferenzen, Referate etc ...?
Irgendwo sehe ich da noch mehrere weitere Denkfehler...
Grüsse
Siramon,
ja der Penner aus Nr. 14-
Nachtrag, da haben wir ein paar (kleinere ;) Denkfehler gemacht, irgendwie sowas also:
Naja, dann mach ich jetzt pro Entität (Workshops, Konferenzen, Referate etc.) 3 Words-Tabellen? Einmal varchar(200) einmal varchar(1000) und einmal text und das jeweils für die Entitäten Workshops, Konferenzen, Referate etc ...?
Irgendwo sehe ich da noch mehrere weitere Denkfehler...
Moment, Du hast für die Entitäten Deine Tabellen und die Attribute zeigen auf zwei unterschiedliche Tabellen ("Words_NVARCHAR" und "Words_NTEXT" bspw.), Fremdschlüssel einrichten, fertig.
-
-
-
Hallo Ludger,
Aha, vielleicht liegt das Problem an den BLOBs.
Warum nicht noch ein:
Words_BLOBsNe, und dann noch ein Words_varchar(x) und ein Words_varchar(y)?? (siehe https://forum.selfhtml.org/?t=146282&m=951306
Regel Nr. 1: Keine zusammengesetzten PKs verwenden.
Die Regel kannte ich noch gar nicht. Quellen?
Grüsse
Siramon,
ja der Penner aus Nr. 14-
Aha, vielleicht liegt das Problem an den BLOBs.
Warum nicht noch ein:
Words_BLOBs
Ne, und dann noch ein Words_varchar(x) und ein Words_varchar(y)?? (siehe https://forum.selfhtml.org/?t=146282&m=951306VARCHAR(X) ist schon ganz OK, ich sehe keinen Grund für bspw. VARCHAR(64) und zusätzlich VARCHAR(1024).
Regel Nr. 1: Keine zusammengesetzten PKs verwenden.
Die Regel kannte ich noch gar nicht. Quellen?Glaube es mir einfach. Bedeutungsbeladene und noch schlimmer bedeutungsbeladene zusammengesetzte PKs erschweren später bspw. die "administrativen Datenarbeiten", also bspw. das Umverzeigern oder Historisieren oder das Re-Design.
-
Hallo Ludger,
VARCHAR(X) ist schon ganz OK, ich sehe keinen Grund für bspw. VARCHAR(64) und zusätzlich VARCHAR(1024).
Äh sorry, SQL Server 2003 gibts ned. Es ist ein SQL Server 2000 (8.x) auf Windows Server 2003.
Bei der 2000er Version (8.0) gibt es kein varchar(max)!
Werde mal eine Wortliste mit varchar(1000) und text einführen...Grüsse
Siramon,
ja der Penner aus Nr. 14-
Bei der 2000er Version (8.0) gibt es kein varchar(max)!
Werde mal eine Wortliste mit varchar(1000) und text einführen...VARCHAR(x) heisst nach meinem Kenntnisstand max. x Zeichen in diesem Feld, also x Byte. NVARCHAR(x) x*2 Byte, entsprechend der Doku http://msdn2.microsoft.com/en-us/library/ms186939.aspx (da hat sich nix geändert).
VARCHAR(x) tendiert zu schlechterer Performance (beisst sich ein wenig mit dem "Seitenkonzept" von MS SQL Server) im Vergleich zu CHAR(x), spart aber Bytes. Mal am Rande - Unicode-Unterstützung sollte Dein System auch mitbringen, also NTEXT- und NVARCHAR(x)-Felder in den zwei Tabellen "Words_<>"?
-
-
-
-
-
-
- Textbausteine in einer Sprachetabelle verwalten ("Wörtertabelle") [4/5] [...]
-
-
Hallo Forum,
Äh, für alle Blacklist-Benutzer, ich führe hier keine Selbstgespräche *g*.
Gibt es keine weiteren Meinung von interessierten Forumsteilnehmern zur "Sprachproblematik" in RDBMS?
Grüsse
Siramon,
ja der Penner aus Nr. 14-
Gibt es keine weiteren Meinung von interessierten Forumsteilnehmern zur "Sprachproblematik" in RDBMS?
Es liegt uns da wirklich auf der Zunge (auch ;) diesen Sachverhalt zu kommentieren. LOL
Aber - und darum melden wir uns an dieser Stelle - Du solltest wirklich mal einen Zwischenstand hier posten, also ein nettes hübsches (bzw. hübsch visualisiertes) ERM http://de.wikipedia.org/wiki/Entity_Relationship_Model , versehen mit einigen Erklärungen und den ins Auge gefassten Beziehungen bzw. Beziehungstypen.
-