madmax_81

Hallo!

Ich denke schon relativ lange über die beste Lösung für folgendes Problem nach.


Ich habe z.b. 2 Tabellen.

Tabelle Rechnungen
id, Kunden_id, datum, preis


Tabelle Kunden
id, name, strasse, plz, ort

Von der Normalisierung her ist dieses Modell richtig. Wenn ich jetzt aber in der Tabelle Kunden z.b. den Namen ändere, ändert sich dieser auf allen bereits erstellten Rechnungen ebenfalls. Das darf natürlich auf keinen Fall sein. Wie löst ihr eine solche Problemstellung? Muss man in so einem Fall auf die Normalform pfeiffen und die Spalten aus der Kundentabelle trotzdem nochmal in der Rechnungstabelle anlegen?

Danke im Voraus!

LG,
Mad

Mister Ad

achtelpetit

Nee, das hat nix mit "auf Normalisierung pfeifen" zu tun, es ist sehr richtig, die fertige Rechnung mit allen Daten zu speichern, übrigens auch die errechnete MwSt., Rabatte und dergleichen.
Es sollte also in der als "fertig" gespeicherten Rechnung nichts mehr von irgendwelchen anderen Daten abhängen.
Es könnte schließlich sein, daß sich im nachhinein irgendwelche Parameter (MwSt.-Satz) ändern oder das sich nachträglich sogar Fehler in der Berechnungsmethode herausstellen. Das darf aber keinen Einfluß mehr auf historische Daten haben.

Edit:
Ich würde eine separate Tabelle "fertigeRechnungen" bevorzugen, eine reine Archiv-Tabelle.

madmax_81

Hallo achtelpetit und danke für deine Antwort!

Genau das war auch mein Gedanke, dass alle relevanten Daten zur Rechnung unabhängig in der Rechnungstabelle nochmals gespeichert sind. Ich war mir nur unsicher, weil es bezüglich Normalisierung nicht der sauberste Weg ist. Aber wie du schon sagst, wie soll man sonst die Konsistenz der Daten Garantieren.

LG,
Mad

achtelpetit

Doch, es ist der sauberste Weg. Eine fertige Rechnung stellt eine eigene Entität dar, an der ich nachträglich kein i-Tüpfelchen ändern darf, also hat sie eine eigene Tabelle "verdient".

ChrisB

Eine andere Möglichkeit wäre, die Adressdaten mit einer Historie zu versehen – bei Änderung der Adresse wird nicht der bestehende Datensatz aktualisiert, sondern ein neuer angelegt, inkl. eines gültig-ab-Datums.
Über letzteres kann zur Rechnung auch im Nachhinein die zu Zeitpunkt der Rechnungsstellung gültige Adresse hinzu gezogen werden.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

achtelpetit

Die Historisierung ist natürlich auch 'ne Möglichkeit, hat aber 2 Nachteile. Erstens muß man bei einer evtl. Änderung der Tabellen auch an die Historisierung denken und zweitens (und das halte ich für ein viel schwierigeres Problem) wird die Rekonstruktion historischer Daten unter Umständen zu einer sehr komplizierten und fehlerträchtigen Angelegenheit.

nikosch

Rechnungsdaten als PDF exportieren und archivieren. Ist unsigniert auch nicht rechtsgültig, aber sicher besser als eine wie auch immer geartete Datenbanklösung.

Kundenverwaltung und Rechnungsarchiv sind schlichtweg zwei verschiedene Anwendungsfälle.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

achtelpetit

Kommt vielleicht auch darauf an, ob öfter mal im Archiv gesucht wird, oder?

madmax_81

Außerdem ist es ganz praktisch, wenn für eine etwaige Weiterverarbeitung der Daten schon alles relevante in einer Tabelle zusammengefasst ist und man nicht x joins machen muss.

mquadrat

Nur ein PDF-Archiv ist ungenügend. Man möchte ja ggf. auch mal eine alte Rechnung kopieren, oder eine Gutschrift basierend auf der Rechnung erstellen.

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de