Rund um Datenbanken

[StepDoWn]

genau, eine person kann öfters vorkommen, aber mit einer anderen rolle (mittels enums würde ich hier in meiner nicht db-struktur eben die werte binär-verodern)

Wiegesagt, eine "eigene" ID für Auftritt vergeben und PK von PersonID weg (im Auftritt-Table), dann ist das Problemchen gelöst.

Zu den enums: ist der richtige Ansatz, in dem Fall ist dein set von Enums ein eigener Table mit nur einem Feld (bzw ID + Feld).

Ein "Auftritt"-Tupel würde dann so aussehen:

(PK)AuftrittID - PK

(FK)PersonID - 1 (referenziert auf Person mit ID 1)

(FK)SendungID - 834 (referenziert auf Sendung mit ID 834)

(FK)Rolle - 7 (referenziert auf Rolle mit ID 7)

Das ist dann auch der "Nachteil" an der Sache, du hast nicht mit einem einzigen Select alle Daten die du brauchst, sondern musst das Konzept von Joins verstehen.

Der Vorteil ist aber klarerweise, dass dein DBMS bei einer Suche nach allen Sendungen mit Regisseur "Stanley Kubrick" nicht den kompletten Sendungs-Table in den Speicher holen musst und jede Zeile mit einem String abgleichen muss, sondern eben einen einfachen Join nach Rollen-ID ausführt (was logischerweise deutlich schneller ist).

Und: wenn du draufkommst dass die Rolle "Regisseur" auf "Regie" geändert werden muss (weil die Grünen im Jahr 2029 zu Martin Ovics Leidwesen die Bundesratswahl mit einem Erdrutschsieg gewonnen haben und durchgesetzt haben dass auch in der Informatik alles gegendert werden muss ), dann änderst du den Eintrag im Rollen-Table einmalig, anstatt dass du möglicherweise zig tausend Strings in deiner Spalte "Rolle" ändern musst.

Je nach Anwendung ist das manchmal also scheißegal, aber sauber ist eine Datenbank dann, wenn sie normalisiert aufgesetzt wird.

Apropos Enums #2: je nach DBMS gibt es enums als eigenen Datentyp. Hierzu allerdings ein Link, der sich zumindest mal auf MySQL bezieht -> http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

[Pimmi]

sorry, ganz auf den thread vergessen

wie gesagt wenn du es so abbilden willst dann würde ich das als gefüllte assoziationen sehen und nicht als alleinstehende entitäten (also die PersonXXX entitäten).

aber grundsätzlich gilt da sowieso: so modellierung wie es für dich am brauchbarsten ist natürlich unter einhaltung der normalformen (zumindest in OLTP). ich persönlich halt nichts davon wenn man z.b. am papier tolle n-äre abhängigkeiten ausmodelliert, wenn man dann in tabellen denkt kann man das in "normalen" binären assoziationen abbilden.

drum bin ich ganz froh in OLAP-Systemen herumzupfuschen, da kann ich mehr oder weniger das tun was mir am besten in's konzept passt

hmm wie wärs korrekt?

[admirana111]

Könnte mir bitte wer kurz in wenigen Worten den Unterschied zwischen relationaler, dynamischer und objektorientierter Datenbank erklären? Vor allem zu dynamisch finde ich kaum etwas im WWW.