Eine temporäre Tabelle für jeden User?

[charlytango]

gerne auch öffentlich, aber dann vielleicht in einem eigenen Fred mit Datenbank/Systemdesign um hier nicht zu stören?

[Luckner]

Ich möchte, deshalb schreibe ich vom "Dokument" folges machen:
Für ein Dokument (Angebot, Auftrag, usw.) möchte ich aus den Stammdaten den Kunden, den/die Artikel und andere Daten importieren. Dann sollte die Möglichkeit bestehen, die Daten wie Kunden, Artikel usw. ändern bzw. ergänzen, ohne die Stammdaten gleichzeitig ebenfalls zu ändern. In dem Moment, wo ein Dokument gespeichert wird werden die direkten Verknüpfungen zu den Stammdaten gekappt und beim nächsten Aufruf dieses Dokumentes sollte kein automatischer Datenimport aus dem Stamm erfolgen. Falls nach einigen Jahren man irgendwelche Artikel im Stamm ändert oder löscht, dann sollte das Dokument jedoch im originalen so bleiben. In der aktl. Faktura bei uns, besteht ein Dokument aus verlinkung von Stammdaten. Für die aktl. Datenbank MS-ACCESS ist es möglicherweise vom Vorteil, weil die Datenbank relativ klein bleibt, jedoch bei einer Änderung im Stamm alle alten Dokumente nur Schrott sind und man muß auf die Archive (in diesen Fall in Papierform) zugreifen.

Gruß, Luckner

[charlytango]

Hi,

ich habe in einer Tabelle Personen und Firmen. Es spricht auch nichts gegen je eine Tabelle für Person und Firma.

Da steht alles drin außer Adresse und Kommunikation, die sind in eigenen Tabellen damit man mehrere Kommunikationen (Mail, Tel, Brieftaube, Mehrdimensionale Raumzeit etc etc.) zuordnen kann.
Gleiches geht mit Adresse, aber da versuche ich doch noch mehr zu normalisieren und Adressen nur einmal im System zu haben. Aber auch das kann man frei Schnauze machen -- kommt auf die Anforderung und den gewünschten Abstraktionsgrad an. (Vielleicht liegt ja auch ein Straßen oder Adressverzeichnis dahinter um Schreibfehler zu vermeiden - zweischneidiges Schwert, Adressverzeichnisse hinken naturgemäß immer hinterher). Prozeduren zur Prüfung der gleichen Schreibweise von Adressen machen immer Sinn.
Hausnummern in ein eigenes Feld, den Rest der Litanei auch wieder in ein eigenes Feld. In AT neben der Straßenbezeichnung Hausnummer,Stiege, Stock,Türnummer. Sonst verweigert der Postbote schonmal die Zustellung.

Allerdings gibt es auch noch eine Adresse und eine Tel/email die ich als gewählte Standardadresse /Standardkommunikation (per Typ) redundant in die Personen/Firmen-Tabelle schreibe(automatisiert).
Dann sind Selektionen für die Benutzer leichter zu verstehen obwohl sie komplexere Strukturen bedienen.

Adressblöcke bei Aufträgen, Fakturen etc etc bestehen daher immer aus der FirmenID, der PersonenID und der AdressID. Wobei diese IDs mehr informellen Charakter und den einer Zuordnung zu einer Personen/Firmaz haben. Wird eine Faktura (oder in deiner Terminologie ein Dokument) bearbeitet passiert außer der Zuordnung erstmal gar nichts. Wird die Bearbeitung beendet und das Dokument freigegeben, wird in einem Textfeld der fertig formatierte Fakturenkopf hinterlegt und festgeschrieben.
Das konserviert den Status zum Zeitpunkt der Fakturenfreigabe, auch wenn sich die Stammdaten (bei Übernahmen ZB auch der Firmenname) über die Zeit ändern sollten.

Gleiches gilt für Fakturenkopf und Zustelladresse. Wobei es die Möglichkeit gibt die Zustelladresse noch zu ergänzen (- "Bei Huber abgeben " oder so). Ähnliches für Lieferschein, soferne nötig.

Somit entsteht ein buchhalterisch valides Dokument. Die Änderung des Geschäftsfalls ist nachträglich nur mehr durch regelkonforme Umbuchungen, Stornierungen, Rücknahmen, Korrekturbuchungen etc. möglich.
Je nach zeitlichem Ablauf durch Rückbuchungungen, Rücknahme von Waren oder auch Rückbuchungen von Rechnungen etc etc. Je nachdem wie der Geschäftsprozess im Unternehmen abläuft.

Oft ist es auch so dass die Artikelbuchungen auf einem Dokument/Faktura nach ähnlichen Regeln laufen müssen bzw auch aus dem Artikelstamm in eine eigene Bewegungstabelle kopiert werden, um historisch Preise und Konditionen ablegen zu können. Demnach können natürlich auch Konditionen des Kunden editiert werden ohne mit den Stammdaten zu kollidieren.

Bei solchen Applikationen kommen schnell mal 100 Tabellen und mehr zusammen. Auch weil zB für jede Dokumenten/Fakturen-Stufe gleich eigene Bewegungsdaten existieren müssen um die nötige Flexibilität bei Buchungen abzubilden.

Also nur so aus dem Nähkästchen geplaudert...

[af0815]

Ich habe gute Erfahrungen gemacht, das man dann die Daten die Konsistenz gehalten werden müssen, aus den Stammtabellen zu nehmen und als XML in einem Feld zu hinterlegen. Der Grund, der MS-SQL kann mit XML auch umgehen und man kann diese Felder ähnlich wie Tabellen abfragen, mit etwas Performance Verlust gegenüber richtigen Tabellen. Das fällt hier aber nicht ins Gewicht.

[charlytango]

Und ich habe schlechte Erfahrungen mit so einem Vorgehen gemacht.
Namentlich in einem Registrierkassenprogramm wo die Entwickler XML-Strukturen und Textfelder gepackt haben.
Anscheinend kann MariaDB auch mit XML-Strukturen in SELECT umgehen.

IMHO sehe ich in einer Warenwirtschaft da bis jetzt keine wirklichen Vorteile.
Aber vielleicht bin ich da auch nur altmodisch.

[af0815]

Ich verwende es nicht laufend, sondern nur für abgelgete Daten. Erst wenn die Buchung quasi abgeschlossen ist und nicht mehr verändert werden darf, dann lege ich die ursprünglichen Stammdaten dort in einer XML Struktur ab. Für das was ich laufend im Select brauche nehme ich natürlich normale Spalten. Wie immer, ist eine Erfahrungs und Geschmacksache.

[charlytango]

Ich verwende es nicht laufend, sondern nur für abgelgete Daten. Erst wenn die Buchung quasi abgeschlossen ist und nicht mehr verändert werden darf, dann lege ich die ursprünglichen Stammdaten dort in einer XML Struktur ab. Für das was ich laufend im Select brauche nehme ich natürlich normale Spalten. Wie immer, ist eine Erfahrungs und Geschmacksache.

so rum kann ich es mir durchaus vorstellen und ist eine Überlegung wert... grübel

[af0815]

Das hat mir jetzt keine Ruhe gelassen - gerade gefunden das des MS-SQL seit der Version 2016 auch mit JSON umgehen kann. Somit kann man für die Dokumentation notwendige Stammdaten nicht nur im XML Format 'archivieren' sondern auch mit JSON. Für mich interessant.

Hinweis: Das Ablegen als xml oder JSON ist extrem SQL-Server abhängig und sicher zwischen den Servern nicht kompatibel, da kein normales SQL.