redundante Datenspeicherung

[khh]

hallo zusammen,
ich überlege gerade, ob es Sinn macht, Kundendaten beim Auftrag oder bei der Rechnung redundant zu speichern?
Die Daten des Kunden können sich ja im Laufe der Zeit ändern, somit habe ich danach die "alten" Daten nicht mehr zur Verfügung.

was meint ihr?

Gruss KH

[DeddyH]

Wenn die Daten historisch nachvollziehbar sein sollen, bleibt Dir IMO gar nichts anderes übrig.

[taaktaak]

Ist die Frage, für wen die Software sein soll. Die Anforderungen werden ggf. durch die Handels- und Steuergesetzgebung sehr umfangreich definiert.

[Billa]

Kommerzielle Software speichert m.W. solche Angaben meist redundant (z.B. Lexware u.ä).

Bei meinen eigenen Programmen mache ich das anders. Die Adressdaten (oder auch Telefon
etc.) werden in eigenen Tabellen gespeichert. Jeder Kunde kann mehrere Adressen haben.
Jeder Adresseintrag hat dabei auch eine zeitliche Gültigkeit. Zur Not geht das natürlich
auch ohne. Die gültige Adresse eines Kunden ist dann einfach immer die jüngste mit der
KundenID.

[khh]

Zitat:

Zitat von taaktaak

Ist die Frage, für wen die Software sein soll. Die Anforderungen werden ggf. durch die Handels- und Steuergesetzgebung sehr umfangreich definiert.

na, dann denk ich wohl bin ich auf jeden Fall auf der sicheren Seite, wenn ich die Daten redundant speichere.
Die Software ist für eine Branche im Einzelhandel.

Gruss KH

[taaktaak]

Sehe ich auch so, allerdings ist (verstehe mich bitte nicht falsch) das "denke ich wohl" eine u.U. recht unsichere Basis für eine professionelle Software-Entwicklung. Ich zitiere mal aus einer spontan gefunden WebAdresse (www.avendata.de):

Zitat:

Eine Software-Zertifizierung nach dem Prüfungsstandard PS 880 des Instituts der Wirtschaftsprüfer (IDW) durch ... ist ein Qualitätssiegel für betriebliche Software-Produkte jeder Art. Vom Kern des Rechnungswesens - der Finanzbuchhaltungs-Software - über Software aus Lager und Produktion bis hin zur Archivierungs-Software können alle Arten von Software der Zertifizierung unterzogen werden.

Eine Zertifizierung ist sicherlich keine Voraussetzung, um Software verkaufen zu können - aber natürlich ein Verkaufsargument und auch ein weitreichender Schutz des Entwicklungsbüros vor etwaigen Regressansprüchen.

[khh]

Zitat:

Zitat von taaktaak

Sehe ich auch so, allerdings ist (verstehe mich bitte nicht falsch) das "denke ich wohl" eine u.U. recht unsichere Basis für eine professionelle Software-Entwicklung. Ich zitiere mal aus einer spontan gefunden WebAdresse (www.avendata.de):

Zitat:

Eine Software-Zertifizierung nach dem Prüfungsstandard PS 880 des Instituts der Wirtschaftsprüfer (IDW) durch ... ist ein Qualitätssiegel für betriebliche Software-Produkte jeder Art. Vom Kern des Rechnungswesens - der Finanzbuchhaltungs-Software - über Software aus Lager und Produktion bis hin zur Archivierungs-Software können alle Arten von Software der Zertifizierung unterzogen werden.

Eine Zertifizierung ist sicherlich keine Voraussetzung, um Software verkaufen zu können - aber natürlich ein Verkaufsargument und auch ein weitreichender Schutz des Entwicklungsbüros vor etwaigen Regressansprüchen.

Die Sofware befindet sich ja momentan noch im Planungsstatus und ist sicher noch weit ab von einer Zertifizierung.
Wobei es sicher eine Überlegung wert ist diese später zertifizieren zu lassen.


Gruss KH

[taaktaak]

Ok, verstehe.
Vermutlich gibt es Informationen über die für eine Zertifizierung zu erfüllenden Anforderungen - die sollten dann tunlichst bereits zum frühestmöglichen Planungstadium der Software berücksichtigt werden.
Ich wünsche dir "Gutes Gelingen"
:thumb:

[khh]

Zitat:

Zitat von taaktaak

Ok, verstehe.
Vermutlich gibt es Informationen über die für eine Zertifizierung zu erfüllenden Anforderungen - die sollten dann tunlichst bereits zum frühestmöglichen Planungstadium der Software berücksichtigt werden.
Ich wünsche dir "Gutes Gelingen"
:thumb:

ich danke dir/ euch



Gruss KH

[mquadrat]

Das Stichwort ist hier "revisionssicher". Da kommt man um redundante Daten nicht herum. Wenn in der Software Prozesse abgebildet werden, muss ggf. auch noch gespeichert werden, welcher Definitionsstand des Prozesses für die Abwicklung des Auftrags verwendet wurde, sonst hat man später viel Spaß mit der Innenrevision.

[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:

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:

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:

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

[globetrotter77]

Zitat:

Zitat von 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

Ich kenne fast ausschließlich Firmen, bei denen mit solchen Dummy-Daten gearbeitet wurde.
Das lässt sich auch nicht ausrotten und muss meiner Meinung nach auch zulässig bleiben.
Die Stammdaten sind für die Revision normalerweise völlig uninteressant, sondern dienen nur als Grundlage für die Neuerstellung von Datensätzen.
Die Prozessdaten dagegen müssen sämtliche prozessrelevanten Einstellungen beinhalten.
Und statt der Lieferanschrift kann übrigens auch mal ganz banal "wird abgeholt" drin stehen!
Das hat dann auch kein Gültigkeitsdatum, sondern ist nur für diesen einen Fall zutreffend.
Vor allem ändert man, wenn der Kunde am Telefon ausnahmsweise so etwas gewünscht hat, nicht gleich die Stammdaten ab.

[Reinhard Kern]

Zitat:

Zitat von Sir Rufo

Aber insgesamt bleibt es halt Geschmckssache ;)

Oliver

Hallo,

nicht nur, es geht auch um den Aufwand beim Programmieren und auch um die einfache Bedienung. Nach der reinen Theorie müsste man eine Tabelle führen für Versandkosten, weil die ja oft gleich sind, aber dann muss der User, wenn er mal was mit Kurier zustellt, erst in den Stammdaten die Versandkostenart Kurier neu erstellen, wozu er möglicherweise keine Berechtigung hat. Also kommen bei mir die Versandkosten einfach als Betrag in den Rechnungssatz, mögen die Theorie-Fanatiker noch so laut schreien. Die Standardwerte kann man ja durchaus aus einer Tabelle mit den wichtigsten Beträgen holen, aber nur als Hilfe beim Rechnungschreiben.

Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

[globetrotter77]

Zitat:

Zitat von Reinhard Kern

Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

Genau! Und für die Hausnummern legen wir auch gleich noch eine Tabelle an!
dto. für mögliche Vor- und Nachnamen ... *grins*

[Blup]

Zitat:

Zitat von globetrotter77

Zitat:

Zitat von Reinhard Kern

Ein weiterer verbreiteter Irrsinn: eine Alexanderstrasse könnte es ja in mehreren Städten geben, also muss die Strasse in eine extra Tabelle - und der User muss für die meisten Kunden erstmal eine neue Strasse anlegen.

Gruss Reinhard

Genau! Und für die Hausnummern legen wir auch gleich noch eine Tabelle an!
dto. für mögliche Vor- und Nachnamen ... *grins*

Da gibts nix zum grinsen. Bei einer automatischen Tourenplanung sind unter Umständen auch die Hausnummern deren Geoposition und auf welcher Straßenseite diese liegen wichtig. Die entsprechenden Daten kann man zu mindest für große Städte auch fertig kaufen.

Natürlich kann die Anwendung auch viele Sachen im Hintergrund erledigen. Zum Beispiel für einen Kunden "Diverse" die entsprechenden Rollen und Adressen anzulegen. Man muss sich nur entgültig von der Ansicht verabschieden, das die Benutzeroberfläche den Datenbankaufbau 1:1 wiederspiegelt.

Zu Tabellen für Vor- und Nachnahmen, wenn du eine Datenbank z.b. für eine Telefongesellschaft erstellst, wirst du genau das tun.
Bei einer Minianwendung die nur tausend Kunden speichert sicher nicht.
Speicherplatz ist Geld, insbesondere wenn man Kosten und Aufwand für Datensicherung und Wartung mit einbezieht.

[Reinhard Kern]

Zitat:

Zitat von Blup

Da gibts nix zum grinsen. Bei einer automatischen Tourenplanung sind unter Umständen auch die Hausnummern deren Geoposition und auf welcher Straßenseite diese liegen wichtig. ...

Hallo,

einfach falsch gelesen: wir machen uns nicht drüber lustig, für die Hausnummern ein eigenes FELD zu reservieren, sondern für diese eine TABELLE anzulegen. Den Unterschied zu erläutern würde aber hier zu weit führen.

Gruss Reinhard

[globetrotter77]

Zitat:

Zitat von Reinhard Kern

einfach falsch gelesen: wir machen uns nicht drüber lustig, für die Hausnummern ein eigenes FELD zu reservieren, sondern für diese eine TABELLE anzulegen. Den Unterschied zu erläutern würde aber hier zu weit führen.

Gruss Reinhard

Genau so meinte ich das auch!
Ich habe es auch schon erlebt, dass jemand eine Tabelle anlegen wollte mit genau einem Feld, das jeweils einen Buchstaben, aber eben nur in z.B. 7 Ausprägungen annehmen durfte. Da platzt mir dann schon die Hutschnur!