Grundlegendes DB Design Frage (Wirklich nur KundenID in Bewegungstabelle verwenden?)

verwendetes Datenbanksystem: MS SQL Server 2008
Ansonsten noch: Visual Studio 2010 Prof, .NET, C#

Hallo!

Plane gerade eine Bestell-Applikation und grübel schon beim aller einfachsten ... 😃

Tabelle: Bestellschein
Tabelle: BestellscheinDetails

Laut "Relationaler DB etc & co" darf/soll/muss ich ja in der Tabelle Bestellschein nur die ID des Kunden eintragen!

Aber was ist, wenn sich der Name des Kunden irgendwann mal ändert (z.b. Heirat) dann würde ich ja rückwirkend die Bestell-Scheine ändern! Ein gedruckter/erledigter Bestell-Schein muss natürlich immer gleich aussehen! Egal wann man ihn druckt!

Wie sieht sowas ein Profi-DB Designer? 😃
Danke & lg myGil

Naja wenn du so vorgehen würdest müsstest du deine Datensätze versionieren und zwar alle die in den Bestellschein einfließen. Grundsätzlich halte ich das aber für die Falsche Taktik da sich ja das Aussehen der Generierten Bestellscheine auch durch Änderungen an dem Programm ändern könnten

Wir haben es immer so gemacht das wir die gedruckten Bestellscheine als PDF gespeichert haben und man sie dann wieder im orginal abrufen konnte.

Hallo mygil,

ich sehe hier 2 Möglichkeiten. Die eine hat Desert Fox beschrieben, aber da kann es Sinn machen PDF/A (spezielles PDF-Vorschrift für die Archivierung) zu verwenden.

Die andere Möglichkeit ist die Bestellschein-Tabelle denormalisiert zu speichern und beim Fremdschlüssel für den Kunden NO ACTION bei ON DELETE und ON UPDATE zu verwenden. Somit sind in der DB immer die ursprünglichen Werte. Eine Layout-Änderung am Renderer erschlägst du damit aber nicht - hier zieht wieder die 1. Möglichkeit.

mfG Gü

Da gibts es mehrere Möglichkeiten. Eine Versionierung der Adressen wäre in der Tat sinnvoll. Denn ein bereits gedruckter Bestellschein soll nicht geändert werden. So schwer ist die Versionierung auch nicht umzusetzen. Eine andere Möglichkeit wäre z.B., in den Bestellschein die komplette Adresse miaufzunehmen. Ist nicht schön, habe ich aber schon bei professionellen ERP Systemen gesehen.

Das ist eines der Probleme das eine Dokumenten basierte DB (aka NoSql ) versucht zu lösen.

Ansonsten musst du bei einer Professionellen SW sowieso jede Änderung protokollieren, also hast du doch auch zu jedem Datum den Kundendatensatz und kannst den dann auch genauso darstellen wie er zum Zeitpunkt der Bestellung war.

Hallo!

Kann hier den Hinweis von Coder007 bestätigen, die meisten ERP-Systeme nehmen die Daten von sich möglicherweise ändernden Basisangaben zusätzlich im Klartext mit auf.

Eine Absicherung gegen spätere Änderungen der Bestellung / Rechnung / ... ist das natürlich nicht, dafür benötigt man nach wie vor andere Möglichkeiten (z.B. signierte PDF's, ...). Aber zumindest hat man auf elektronischem Wege im System schnell Zugriff auf die alten (korrekten) Daten.

Irgendwie gefällt mir die denormalisierte Variante (also die Daten einfach mit in die Bestellung zu nehmen) am besten!

Mein Grund:

1. Der Inhalt muss stimmen und das Layout ist mir egal!
2. Einfachheitshalber

Irgendwie gefällt mir der Gedanke, dasss ich die KundenID + die Daten zur zeit der Bestellung aufnehme - so könnte ich auch in der Applikation darauf Hinweisen, dass sich die Kunden Daten inzwischen geändert haben ...

Special Thanks @ ALL:
tom-essen
FZelle
Coder007
Desert Fox

Vielen Dank für die Antworten!

Hi,

bei unserem ERP wurde das genauso gelöst.

Hat noch einen großen Vorteil:
Stell dir vor die verschickst was an den Frankfurter Flughafen :
Die eigentliche Adresse ist klar - jetzt musst du aber noch Gebäude, Raum, Ansprechpartner
und was weiß ich nicht was ändern.

Normalisiert müsste man immer eine neue Adresse anlegen -
selbst wenn es die selbe (Sub)Firma im selben Gebäude ist.

Bei uns kann man jede Adresse komplett selbst auf jedem Beleg umschreiben und gewinnt
dabei viel Flexibilität.

Ich allerdings würde nur die Änderung von vorher leeren Feldern zulassen.
(Rein theoretisch kann ich bei uns nach Zimbabwe verschicken obwohl der Kunde
in Frankfurt ist - die Möglichkeit würde mir als Chef mit diesem Hintergrund missfallen 😉)

LG
Achim