2 Fragen zu einem schalen Datenmodell

Hallo,

Für ein Programm, das ich machen will habe ich zwei Fragen für mein möglichst performantes DB-Modell:

  1. Welcher Ansatz ist besser ? Eine grosse Tabelle oder eine Haupt-Tabelle mit gemeinsamen Feldern und mehrere Detail-Tabellen ? Ich habe eine Liste von Records, die je nach Art andere Detailinformationen benötigen. Also entweder eine grosse Tabelle, wo die unnötigen Felder mit NULL leergelassen werden, oder je nach Art-Code einen Join auf die entsprechende Detail-Tabelle. Ich denke mal die Detail-Tabellen-Lösung ist besser. Obwohl NULL ja eigentlich nichts ist und somit nicht stören sollte in der Performance.

  2. History & „Papierkorb“
    Um eine History und sogar einen Papierkorb zu ermöglichen, viel mir spontan eine einfach Lösung ein: Einfach zwei weitere Felder „Modifukationsdatum“ und „Löschdatum“. Der Record, wo beides NULL ist, wäre also gültig, die änderen gehören dann der History-List bzw. dem Papierkorb ab. Hierzu meine Frage: Taugt dieser Ansatz etwas in der Praxis ? Mein Bedenken: Mit der Zeit wird die TBL ziemlich aufgebläht, aber man könnte das ja auf z. b. 10 History-Einträge limitieren. Wird das Zusammen mit der Detail-Lösung genommen, müssten ja auch die Detail-Tabellen diese beiden „Steuerungsfelder“ haben.

Vielen Dank für eure Kommentare hierzu :wink:

Roger

Hallo.

  1. Welcher Ansatz ist besser ? Eine grosse Tabelle oder eine
    Haupt-Tabelle mit gemeinsamen Feldern und mehrere
    Detail-Tabellen ? Ich habe eine Liste von Records, die je nach

Weitmöglichst atomisieren, lautet mein Rat. Der Wert NULL ist zwar nitschewo (ist eigentlich auch nicht exakt, weil NULL NUll ist und nicht nix ), das Feld jedoch belegt trotzdem seinen Platz.

  1. History & „Papierkorb“
    Um eine History und sogar einen Papierkorb zu ermöglichen,
    viel mir spontan eine einfach Lösung ein: Einfach zwei weitere
    Felder „Modifukationsdatum“ und „Löschdatum“.

So weit nicht falsch. Nur würde ich die ungültigen Records nicht in der Tabelle lassen, sondern per SQL in ein oder besser zwei (Großvater- Vater- Sohn- Prinzip) beamen. Das Zurückholen alter Datenbestände ist ja nicht der Regelfall; die ständig im Zugriff befindliche Tabelle sollte möglichst klein gehalten werden (Transferleistung).

Gruß kw

NB : Wieso eigentlich schal? owT
Gruß kw

das sollte „schlau“ heissen :stuck_out_tongue: