Designentscheidung

Moin,

für ein SW-Projekt soll auch eine DB Verwendung findet. Nun stehen wir
vor dem Problem, Daten auf Relationen abzubilden. Ich möchte euch kurz
die Daten erklären und die bisher zur Diskussion stehenden Möglichkei=
ten.

Es sollen Referenzen verwaltet werden. Von diesen gibt es 13 Typen. Es
gibt ein paar Attribute (z.B. Titel, Jahr, usw.), die alle Referenztypen
haben. Andere Attribute (z.B. Autor, Organisation, usw.) kommen nur bei
einigen Referenztypen vor.

Kleines Beispiel:

Typ 1:
Attribute: Titel, Jahr, Autor, X, Y

Typ 2:
Attribute: Titel, Jahr, Organisation, Y, Z, U

Typ 3:
Attribute: Titel, Jahr, U, V

usw.

Zur Diskussion stehen die Möglichkeiten, alle Referenzen in _einer_
(breiten) Tabelle zu halten oder aber in 14 (eine Tabelle pro Typ und
noch eine für die gleichen Attribute aller Referenztypen) verschiedenen=

Tabellen.

Vorschlag 1:
------------

Tabelle:

id | Titel | Jahr | Autor | Organisation | X | Y | Z | U | V


Vorschlag 2:
------------

Tabelle 0:

id | Titel | Jahr | ReferenzTyp

Tabelle 1:

id | Autor | X | Y

Tabelle 2:

id | Organisation | Y | Z | U

Tabelle 3:
id | U | V

usw.

Dabei hat eine Referenz nur eine id. Die vollständige Referenz bildet
sich somit aus zwei Tabellen (Tabelle 0 und je nach ReferenzTyp eine der
Tabellen 1 bis 13).

So langsam frage ich mich, ob die zusätzliche Tabelle 0 einen großen
Sinn hat oder ob die gemeinsamen Attribute nicht in den Typ-Tabellen
genauso gut oder besser aufgehoben sind?!

Die Argumente für _eine_ Tabelle waren schnell gefunden, wie z.B. die
einfache Suche über alle Referenzen und alle Attribute (unabhängig vo=
m
Typ) inkl. Sortierung nach bestimmten Attrubuten durch das DBMS.

Mir sagt diese Entscheidung allerdings nicht zu. Mit dieser Meinung bin
ich aber eher alleine und suche nun hier Meinungen, die mich
unterstützen oder vom ersten Vorschlag überzeugen.

Wie würde eigentlich die Suche, inkl. Sortierung nach bestimmten
Attributen, beim zweiten Vorschlag (mit 14 oder 13 Tabellen) aussehen?
Kann das (einfach) in _einer_ Abfrage erfolgen?

Dann mal ran an die Argumente. :)

Vielen Dank,
Edvin Pelivanovic

Re: Designentscheidung

Hi Edvin

Edvin Pehlivanovic wrote:
> Es sollen Referenzen verwaltet werden. Von diesen gibt es 13 Typen. Es
> gibt ein paar Attribute (z.B. Titel, Jahr, usw.), die alle Referenztypen
> haben. Andere Attribute (z.B. Autor, Organisation, usw.) kommen nur bei
> einigen Referenztypen vor.
> Zur Diskussion stehen die Möglichkeiten, alle Referenzen in _einer_
> (breiten) Tabelle zu halten oder aber in 14 (eine Tabelle pro Typ und
> noch eine für die gleichen Attribute aller Referenztypen) verschiedenen
> Tabellen.

Als dritte Variante gäbe es die Handorgel. Das heisst, du transponierst
die breite Tabelle:

References:
id
Titel
Jahr
usw.

AttributeTypes:
idReferences
nameAttribute

Attributes:
idReferences
idAttributeTypes
value

Je nach dem, wie du das ganze danach handhaben willst, ist das eine oder
andere besser geeignet. Diese Entscheidung liegt aber bei dir. Bei 13
Typen ist das alles vielleicht noch übersichtlich. Ich hatte da aber ein
Projekt, wo die Anzahl der differenten Objekttypen undefiniert blieb.

HTH, Johannes

Re: Designentscheidung

Edvin Pehlivanovic schrieb:
> Wie würde eigentlich die Suche, inkl. Sortierung nach bestimmten
> Attributen, beim zweiten Vorschlag (mit 14 oder 13 Tabellen) aussehen?
> Kann das (einfach) in _einer_ Abfrage erfolgen?

einfach kaum.

Eventuell mit komplizierten union-abfragen ... die zweite Lösung würde
immer voraussetzen, dass du den Typ kennst, bevor du abfragst, oder 13
Abfragen machen musst. Da würd ich nie einen Vorteil drin sehen.

Warum die Typenfestlegung? Bedeutet es, dass Typ X _unbedingt_ die
Eigenschaften ... haben MUSS? Oder ist er Typ X wenn er die mindestens
die für den Typ X erforderlichen Eigenschaften hat, und kann
gleichzeitig auch Typ Y sein, weil er noch zusätzlich Eigenschaften ...
hat? Das würde für eine breite Tabelle sprechen.
Wenn die Breite jetzt über 10, 20 ... hinausgeht, oder für jede
Eigenschaft mehrere Einträge nötig wären, ist die schon gepostete
Aufteilung interessant, erfordert aber sql-technisch _wesentlich_
komplexere Abfragen. Mit dem Vorteil, dass eine Referentz eventuell zwei
Autoren (Autoreneinträge), oder auch mehrere Jahreseinträge haben könnte.

Michael