redundante Datenspeicherung

[hazard999]

Möglich wäre es auch bei jeder Änderung ein neues Record in der Kundentabelle anzulegen
und den alten als deprecated zu definieren.

[WS1976]

Hallo,

jede vernünftige Firma wird ihre Datenbestände per Band oder ein anderes Medium sichern.
Wir z.B. sind verpflichtet unsere Datenbestände 10 Jahre aufzubewahren.
Ich weiss, dass mein Beitrag etwas am Thema vorbei geht aber wird täglich eine Sicherung gemacht
in einer Monatssicherung zusammengefasst und diese 10 Jahre aufgehoben so hast du immer
noch die Möglichkeit an deine alten Daten zu kommen.
Ich möchte auch noch das Stichwort "optisches Archiv" in den Raum stellen.
Ansonsten müsstest du dir soetwas wie eine Backup-Datenbank zulegen in der jede Änderung
gespeichert wird. Halte ich für unrealistisch!

Grüsse
Rainer

[himitsu]

OK, das Backup ist schonmal gut, aber wenn er "schnell" mal auf alte Daten zugreifen will, dann würde ich je eine zusärtliche Tabelle anlegen, wo die "alten" Daten reinverschoben werden, mit einem zusätzlichen Feld für das Änderungs/Löschungsdatum.

Die Daten würden dann die aktuelle Tabelle nicht belasten
und man könnte sowas wie eine History in sein Programm einbauen, wo man sich zu einen Datensatz die letzen Änderungen anzeigen lassen könnte.

Zu alte Daten und jene, welche nicht mehr benötigt werden, könnte man dort ja wieder rauslöschen lassen. Für den Notfall, daß man dann doch mal viel ältere Daten benötigt, könnte/müßte man sich dann halt das passende Backup raussuchen.

[Billa]

... und da komme ich wieder mit meinem Vorschlag:
Adressdaten in eigene Tabelle. Jeder Satz hat einen
referentiellen Bezug auf die Kundentabelle und ein
Gültigkeitsdatum ... Das ist gleichzeitig auch ein Archiv

[mquadrat]

Eine Tabelle in der mit einem extra Gültigkeitsdatum gearbeitet wird, macht nur Sinn wenn man die Daten immer aus dem Kundenstamm holt und im Einzelfall nicht mehr ändert. Beispiel Zahlungsart: Wenn alle Vorgänge über die Zahlungsart gehen, die im Kundenstamm verknüpft sind kann man mit der Referenztabelle arbeiten, wird aber für einen Vorgang eine abweichende Zahlart vorgesehen so müssen die Daten beim Vorgang gespeichert werden.

[Reinhard Kern]

Zitat von mquadrat:

Eine Tabelle in der mit einem extra Gültigkeitsdatum gearbeitet wird, macht nur Sinn wenn man die Daten immer aus dem Kundenstamm holt und im Einzelfall nicht mehr ändert. Beispiel Zahlungsart: Wenn alle Vorgänge über die Zahlungsart gehen, die im Kundenstamm verknüpft sind kann man mit der Referenztabelle arbeiten, wird aber für einen Vorgang eine abweichende Zahlart vorgesehen so müssen die Daten beim Vorgang gespeichert werden.

Hallo,

endlich jemand, der neben der Diskussion um relationale Tabellen auch etwas von der Sache selbst versteht. Eine Rechnung ist eine Rechnung ist eine Rechnung und keinesfalls darf daran etwas geändert werden, wenn sie mal gedruckt ist. Selbst wenn ein Tippfehler vorliegt, ist nur Stornieren und Neuanlegen zulässig! Es darf nie der Fall eintreten, dass 2 gedruckte Rechnungen gleicher Nummer existieren, die sich irgendwo unterscheiden.

Ich halte daher das spätere Hereinmixen von Daten aus dem Kundenstamm (oder Warenstamm usw.) für generell nicht zulässig - was auf der Rechnung steht, muss auch im Rechnungsdatensatz gespeichert werden, relationale Theorie hin oder her. Nur zum Zeitpunkt der Rechnungserstellung werden die aktuellen Stammdaten eingelesen. Nach aussen hin wäre daher auch eine Speicherung im PDF-Format denkbar, womit diese Fragen erledigt wären, aber dann kann man die Rechnungsdatensätze nicht mehr statistisch auswerten.

Gruss Reinhard

[Billa]

Das Eine schließt das Andere ja nicht aus, oder? Gefordert ist doch
lediglich Eindeutigkeit der Zuordnung, das physische Modell "darunter"
ist m.E. zweitrangig. Mein Vorschlag soll auch nur als Hinweis dienen,
wie so etwas mit wenig Aufwand zu realisieren ist. Ob ich "beim Vorgang"
speichere, oder an anderer Stelle mit eindeutiger Verknüpfung kann
wohl keine so große Rolle spielen. Entscheidend ist die "Business-Logik",
eine nachträgliche (verbotene) Manipulation könnte schließlich auch stattfinden,
wenn die Daten physisch in derselben Tabelle stehen.

[Blup]

Zitat von mquadrat:

Eine Tabelle in der mit einem extra Gültigkeitsdatum gearbeitet wird, macht nur Sinn wenn man die Daten immer aus dem Kundenstamm holt und im Einzelfall nicht mehr ändert. Beispiel Zahlungsart: Wenn alle Vorgänge über die Zahlungsart gehen, die im Kundenstamm verknüpft sind kann man mit der Referenztabelle arbeiten, wird aber für einen Vorgang eine abweichende Zahlart vorgesehen so müssen die Daten beim Vorgang gespeichert werden.

Das ist nicht ganz richtig. Es muss nur klar sein, das eine einfache Historie nicht genügt.
Erforderlich ist ein Protokoll, das den Zustand der entsprechenden Stammdaten zu jedem Zeitpunkt, insbesondere der Rechnungslegung wiederspiegelt.

Eine Historie kann ich im nachhinein ändern oder es können auch schon zukünftige Änderungen erfasst werden.
Beispiel für eine Historie von Adressen eines Kunden

ID_KD, GUELTIG_AB, STRASSE
17012, "05.12.1980", "Blaustraße 1"

Der Kunde teilt uns mit, er zieht in 5 Wochen um:

ID_KD, GUELTIG_AB, STRASSE
17012, "05.12.1980", "Blaustraße 1"
17012, "06.03.2009", "Grünstraße 2"

Eine Rechnung am "02.03.2009 10:03" erstellt, wird an die "Blaustraße 1" adressiert.

Eine Wochen später teilt uns der Kunde mit, er ist doch schon 2 Wochen früher umgezogen:

ID_KD, GUELTIG_AB, STRASSE
17012, "05.12.1980", "Blaustraße 1"
17012, "20.02.2009", "Grünstraße 2"

Wenn wir uns jetzt beim Druck einer Rechnungskopie auf die Historie verlassen, erscheint auf der Rechnungskopie plötzlich "Grünstraße 2".


In einem Protokoll gibt es praktisch nur Inserts(kein Update oder Delete).
Deshalb ist es möglich die für die Rechnung gültige Straße eindeutig zu bestimmen:

ID, GEAENDERT, ID_KD, GUELTIG_AB, STRASSE
1, "05.12.1980 10:13", 17012, "05.12.1980", "Blaustraße 1"
2, "09.02.2009 13:45", 17012, "06.03.2009", "Grünstraße 2"
3, "05.03.2009 09:30", 17012, "20.02.2009", "Grünstraße 2"

Der Eintrag mit der ID=3 darf für die Rechnungskopie nicht berücksichtigt werden, da GEAENDERT > Zeitpunkt der Rechnungserstellung.

select strasse
from tabelle
order by id_kd desc, geaendert desc
where (id_kd = :id_kd) and (geaendert <= :rechnungserstellung)
rows 1

Der Einfachkeit halber kann man bei der Rechnung auch einfach die ID aus dem Protokoll speichern.
Damit ersparrt man sich auch Ärger mit ungenauem Zeitstempeln oder eventuell parallelen Transaktionen bei der Rechnungserstellung.

[Reinhard Kern]

Zitat von Blup:

Das ist nicht ganz richtig. Es muss nur klar sein, das eine einfache Historie nicht genügt.
Erforderlich ist ein Protokoll, das den Zustand der entsprechenden Stammdaten zu jedem Zeitpunkt, insbesondere der Rechnungslegung wiederspiegelt....

Hallo,

mit dem Zugriff über eine eindeutige ID kann man die Sache sicher in den Griff bekommen, vorausgesetzt man beachtet auch die Möglichkeit von ad-hoc-Vereinbarungen wie geänderte Zahlungsziele, Skonti usw. und speichert diese mit der Rechnung ab.

Bei unserer Anwendung kamen aber noch weitere Randbedingungen dazu: Ossi-Fertigung und Wessi-Verwaltung mit ca 500 km Entfernung. Daher enthält die Rechnungsdatenbank alles, was in der Rechnung steht und wird jeden Morgen übertragen. Wegen der Besonderheit, dass vorhandene Rechnungen nicht geändert werden dürfen, genügen dabei die neu erstellten Rechnungen, eine Datenmenge von weniger als 100 kB.

Wäre alles relational verknüpft, so müsste ein konsistenter Snapshot des ganzen Systems mit Kundendaten, Artikeldaten, Material usw. übertragen werden, das wären 25 - 50 MB. Eine Online-Datenverbindung von Server zu Server wäre natürlich nicht uncool, aber zum Zeitpunkt, als das alles konzipiert wurde, wären die Kosten im Bereich kEUR/Monat gelegen.

Gruss Reinhard

[Sir Rufo]

Manchmal wird die Art der Speicherung auch durch die Arbeitsweise festgelegt ...

Ich betreue auch einen Einzelhandel und da ist bei der Auftragserstellung/Rechnung der Divers-Kunde sehr beliebt.

Eine Dummy-Kunden-Nummer, wenn der Kunde nicht dauerhaft gespeichert werden soll.

Also wird die Adresse einfach im Rechnungskopf gespeichert. Somit revisionssicher und auch Diverskunden-fähig.

Als weiterer Hinweis ist die Angabe der Lieferschnschrift, die sich ja auch von Auftrag zu Auftrag ändern kann (mal für die Omi, mal für wen auch immer). Auch hier werden diese Daten im Rechnungskopf gespeichert.

Weiterer Vorteil: Bei einer Revision werden nur die Tabellen Rechnungskopf und Positionen benötigt. Eine Verknüpfung mit den Adress-Bestönden entfällt.

Aber insgesamt bleibt es halt Geschmckssache

cu

Oliver