Datenbankstruktur

[wolle190480]

Hallo,

ich bin ein Neuling auf dem Gebiet Datenbanken und habe noch einige Startschwierigkeiten bei meiner Datenbank ;-)

Ich schildere mal kurz meine Überlegungen. Um Einsätze bei Kunden erfassen zu können hätte ich folgende Datenbanken angelegt:

1. Kundendatenbank (Name, Adresse, .....)
2. Besuch (Datum, Dauer, Art des Kundenbesuchs,...)

Nun möchte ich aber je nach Art des Kundenbesuchs unterschiedliche Felder befüllen. Also wenn es sich z.B um ein Beratungsgespräch handelt möchte ich andere Felder befüllen als bei einem Folgegespräch.
Meine Überlegung wäre gewesen, dass ich pro ART des Kundenbesuchs eine eigene Tabelle erstelle mit den Feldern die befüllt werden sollen.

Also soll die Tabelle Besuch mehrere Untertabellen haben, je nachdem welche Art des Kundenbesuchs es ist.

Funktioniert das so wie ich mir das vorstelle oder bin ich auf dem Holzweg und es geht viel schöner zu lösen ?

Vielen Dank schonmal im Voraus!

LG Wolfgang

[fanderlf]

Vererbung ist nicht so die Spezialität eines RDBMS

Ich würde es davon abhängig machen wieviele Felder unterschiedlich sind. Wenn es nur ein paar Felder sind die sich unterscheiden, dann würde ich das ganze in eine Tabelle basteln. Das ist mit Sicherheit leichter zu handhaben, als sämtliche Information auf mehrere Tabellen zu verstreuen.
Zumal ja die meisten Eigenschaften (Felder) eines Besuchs wahrscheinlich den gleichen Sinn haben dürften. Wenn Du alles in einer Tabelle hast könntest Du evtl. auch die Besuche miteinander verknüpfen. So kann der erste Besuch z.B. mit dem Folgebesuch verknüpft werden. Das gestaltet sich sehr schwer wenn Du die Daten über mehrere Tabellen verteilst.

[tinof]

Hallo,

ich habe z.B. eine Auftragsbearbeitung 'im Angebot', bei der verschiedene Positionen in Belege geschrieben werden: Artikelverkäufe, Einkäufe, Langtexte, Positionsrabatte ...

Ich habe das alles in einer Tabelle mit entsprechend vielen spezifischen Feldern.

Zwar wäre die typabhängige Speicherung in je einer 'optimierten' Tabelle ressourcenschonender und über ein UNION ALL bekäme man sogar eine gemeinsame Auflistung, aber

- spätestens beim Löschen gibts mit so einer UNION ALL - Abfrage Probleme
- Speicherplatz ist nicht mehr so teuer, man darf es sich ruhig leicht machen und ein paar Ressourcen 'verbraten', schließlich wird das Handling dadurch einfacher
- wenn man mit varchar - Feldern arbeiten kann, wird das reine Platzproblem zusätzlich entschärft
- die in mehreren spezialisierten Tabellen immer wieder notwendigen Header - Infos bringen bei einer 'eine Tabelle pro Typ' - Variante genauso Redundanzen

- auch für die Darstellung der Daten im Programm ist eine Tabelle einfacher als mehrere: In der Regel verwendet man ja irgendein Grid oder eine Liste - das mit unterschiedlichen Basis- Recordsets hinzubekommen ist sehr schwierig.
- auch die chronologische Reihenfolge läßt sich einfacher mit einer Tabelle sicherstellen.

Also, ein klares Pro 1 Tabelle.

Viel Erfolg
Tino

[Markus Kinzler]

Eien Tabelle ist aus meiner sicht die schlechtere Möglichkeit. Da hier schnell Redundanz und Unübersichtlichkeit geschaffen wird. Für eine Auswertung kann man die Tabellen ja immer noch Joinen

[fanderlf]

Aber wenn ich für jeden Objekttyp eine eigene Tabelle anlege schaffe ich auch Redundanz. Ich muss Typen die in allen diesen Objekten vorkommen in jeder Tabelle einzeln Pflegen, habe somit sämtliche Logik redundant in der Datenbank abgelegt. Wenn ich alle Felder in eine Tabelle packe, dann muss ich bei einem Update der Oberklasse genau ein Feld nachpflegen und nicht in jeder Tabelle der Unterklasse.
Aber wie mans dreht und wendet. Für Vererbung gibt es einfach kein passendes relationales Datenmodell

[wolle190480]

Hallo,

vielen Dank für eure Antworten! Ich denke mal dass ich für mein Startprojekt mal den einfacheren Weg wähle und nur eine Datenbank dafür anlege.
Danke für euer input!

LG Wolfgang