nicht angemeldet
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.