DB Design Frage

[lepper01]

Hallo zusammen,

ich habe ein paar Fragen zu DB Design. Ich möchte Euch um Rat fragen, wie Ihr es lösen würdet.

Hier die Aufbau:
Ein Packet beinhaltet verschiedene Botschaften, Botschaften beinhalten verschiedene Signalen, welche wieder verschiedene Attributen haben.

Beispiel Aufbau:

Packet A beinhaltet
Botschaft_1
Botschaft_2
Botschaft_3
Botschaft_xx

Botschaft_1 beinhaltet:
Signal_1_1
Signal_1_2
Signal_1_xxx

Botschaft_2 beinhaltet:
Signal_2_1
Signal_2_2
Signal_2_xxx

usw

Es kann mehrere Versionen von Packeten geben z.B. Packet(n), welche viele gleiche Botschaften beinhalten wie Packet(n-1) aber es sind einige neue Botschaften dazugekommen bzw. welche gelöscht worden. Das gleiche kann mit Signalen passieren, die können einer Botschaft dazukommen bzw. entfallen.

Ich möchte z.B. viele Vergleiche machen z.B. Unterschiede zwischen Packet(n) und Packet(n-1) und Packet(n-2). Ach nochwas, ein Packet beinhaltet ca. 200 Botschaften und eine Botschaft ca. 10 Signalen --> ein Packet wird 2000 Signalen haben. Ich habe z.B. etwa 100 Packeten --> 100*2000 = 200000 Signalen. Es kann aber viel mehr werden.

Hier meine Vorschläge, was meint Ihr?





Danke für Hinweise und viele grüße

 

[akretschmer]

Also ich würde auf 2 tippen.

 

[lepper01]

Hallo,

aus welchem Grund? Lösung 1 erzeugt viele redundante Daten, aber dafür 2 Tabellen weniger....hmmm....

grüße

 

[akretschmer]

Hallo,

aus welchem Grund? Lösung 1 erzeugt viele redundante Daten,

grüße

deswegen.

 

[Hony%]

Hi

Lösung 1 erzeugt viele redundante Daten

Mein erster Gedanke war ebenfalls das Schema zu normalisieren um so Redundanzen zu vermeiden. Allerdings weißen deine Bezeichnungen darauf hin, dass es sich möglicherweise zwar um in ihrer Repräsentation identische Daten jedoch nicht um redundante handelt.

Nehmen wir an dass Signal_1_2, der Repräsentation nach, identisch zu Signal_2_2 ist. Nehmen wir weiter an, dass du die Repräsentation von Signal_1_2
ändern möchtest. In diesem Fall würde durch die Normalisierung dein Eingriff Signal_2_2 auf unzulässige Weise beeinflussen da es sich dabei um eigenständige Informationen handelt und eben nicht um eine redundante Speicherung.

Vielleicht hilft dir der Gedanke ja weiter.

Gruß
Hony

 

[lepper01]

na ja, bei einer Änderung von Signal_1_2 werde ich dann neue Version anlegen. Oft ist so, dass zwischen Packet Version 1 und Packet Version 2 80% Inhalt gleich ist. Zweitens die Packete werden aus einer XML Daatei eingelesen (etwa 5 mal im Jahr) und zu jedem Signal wird es noch zusätzlich 20 Attributen geben, welche ich händisch nachpflegen muss (es sind halt Requirements). Ich möchte beim Packet Verion 2 die Sachen von Packet Version 1 vererben. Es werden hauptsächlich viele Vergleiche zwischen Packeten, Botschaften und Signalen durchgeführt.

 

[Hony%]

na ja, bei einer Änderung von Signal_1_2 werde ich dann neue Version anlegen.

Ich denke das stützt meinen Gedanken sogar noch. Natürlich kannst du hier normalisieren um vermeintliche Redundanzen zu entfernen. Faktisch erzeugst du aber nur eine Kompression und sparst damit etwas Speicherplatz.

Zweitens die Packete werden aus einer XML Daatei eingelesen (etwa 5 mal im Jahr)

Hier stellt sich die Frage ob eine relationale Datenbank dann überhaupt das richtige Werkzeug ist und ob nicht eine Datenbank mit XML Werkzeugen besser geeignet ist. Die großen relationalen Datenbanken besitzen allerdings für gewöhnlich die Möglichkeit mit XML direkt umzugehen.

und zu jedem Signal wird es noch zusätzlich 20 Attributen geben, welche ich händisch nachpflegen muss (es sind halt Requirements).

Diese Anforderung spricht nicht gegen deine Lösung 1. Die zusätzlichen Attribute können problemlos in einer weiteren Tabelle gepflegt und per Fremdschlüssel mit den Signalen verknüpft werden. Das muss nicht zwangsläufig mehr Arbeit bedeuten.

 

[lepper01]

Ich denke das stützt meinen Gedanken sogar noch. Natürlich kannst du hier normalisieren um vermeintliche Redundanzen zu entfernen. Faktisch erzeugst du aber nur eine Kompression und sparst damit etwas Speicherplatz.

Ja schon, aber bei Vergleich muss ich Millionen von Datensätzen durchgehen und alle Spalten vergleichen --> kostet Zeit und Performance. Sonst brauch ich nur IDs (nur eine Spalte anstaat 50 Spalten pro Datensatz) vergleichen.

Hier stellt sich die Frage ob eine relationale Datenbank dann überhaupt das richtige Werkzeug ist und ob nicht eine Datenbank mit XML Werkzeugen besser geeignet ist. Die großen relationalen Datenbanken besitzen allerdings für gewöhnlich die Möglichkeit mit XML direkt umzugehen.

Na ja, ich hab doch nicht alles geschrieben, es gibt niccht nur XML Files aber auch proprietäre Datenformate.

Diese Anforderung spricht nicht gegen deine Lösung 1. Die zusätzlichen Attribute können problemlos in einer weiteren Tabelle gepflegt und per Fremdschlüssel mit den Signalen verknüpft werden. Das muss nicht zwangsläufig mehr Arbeit bedeuten.

Ich muss mich auch hier korrigieren, es werden mehr als 20 Spalte, sagen wird 50 und daraus werden mehrere Tabellen entstehen.