Office: (Office 2016) Auftragsverwaltung sinnvolle Tabellenaufteilung

Ich würde gern unsere Datenbank überarbeiten und somit kleinere Fehler bei der Datenbankstruktur korrigieren. Aktuell erfolgt die Abwicklung über folgende Tabellen:
Bestellungen: Datum, Lieferart, KuNr usw
Auftrag - Rechnung: ReNr, Auftragsart (Rechnung, Garantie usw.), Versand, Datum Versand, Datum Geldeingang, Versandzuschläge, Steuersatz (wird gelöscht, gehört in andere Tabelle)
Auftragsdetails: Artikelnummer, VE-Inhalt, Anzahl, Preis, Steuersatz, Rabatt
Die Grundstruktur ist recht praktikabel, aber ich denke, bestimmte Felder wären in anderen Tabellen besser aufgehoben (Lieferart aus Bestellungen könnte in die Rechnungstabelle), bin aber unschlüssig oder zu festgefahren in unserem System. Weiterhin zebreche ich mir den Kopf über folgendes:
In unserem Onlineshop werden die Rechnungssummen, MwSt Anteil usw. in Tabellen gespeichert. Ist das denn sinnvoll? Ich war der Meinung, berechnete Felder werden nicht gespeichert. Im Onlineshop werden auch zu jeder Order die Rechnungs-und Lieferanschrift gespeichert. Ich hätte dies über eine Adresstabelle gelöst und die Adress-ID im Auftrag gespeichert. Allerdings würden sich dann auch vorhergehende Rechnungsdetails ändern, wenn man die Adressen in der Adresstabelle ändert - also scheint das Abspeichern der Anschrift im Auftrag doch sinnvoll zu sein.... Was aus Sicht der Buchhaltung richtig ist, widerspricht aber den Datenbank-Grundsätzen.

Wer kann Licht ins Dunkel bringen?

:)

 

Hallo Bernd?,

der untere Teil deiner Überlegungen ist schon richtig.
Ein richtiges Datenmodell ist superwichtig.
Fehler dort werden dich begleiten und manche Sachen sind ohne umfangreiche Programmierung nicht zu lösen.

Einen Überblick bietet die Nordwind-Datenbank von MS.
Überblick! keine Lösung.

Einiges kann man übernehmen, aber nicht alles.

Du willst ja auch nicht alles neu machen?
Zeige mal das Beziehungsfenster. Dann kann man schon einiges beurteilen.

Gruß
Rainer

 

Servus aolbernd,
1 - kontaktiere doch als erstes mal den Ersteller Deiner DB und diskutiere mit
ihm Deine Fragestellungen.
2 - kontrolliertes und absichtlich redundantes Speichern von Daten ist sinnvoll.
Dazu bedarf es aber einer Diskussion in 1.
3 - Ohne den Snapshot eines übersichtlichen Beziehungsfensters Deiner DB
wird es wohl unmöglich sein, Dir da weiterhelfen zu können.

 

Gesunde Datenmodellierung heißt, einen gesunden Kompromiss zwischen ausgefeilter Theorie und praxisbezogener Funktionalität zu finden.

Bei Übernormalisierung - ich denke da beispielhaft an Möglichkeiten im Bereich Orte, Straßen, Postleitzahlen - hat man dann schon einigen Aufwand (Erstellung Abfrage, dann aber auch laufende Ausführung), aus den Tabellen geeignete einfache Listen zusammenzustellen, von "richtigen" und anspruchsvollen Abfragelösungen mal ganz zu schweigen. Wer vertieft sich schon in Abfrageerstellung über das Zusammenklicken von irgendetwas in der Entwurfsansicht hinaus?

Zum Thema Mehrwertsteuer gibt es hier in den Untiefen des Forums einen hübschen Beitrag: Anfängerfrage bzgl MWst Berechnung
Unter dem Strich: Alles immer live neu errechnen zu wollen könnte eine riesige Herausforderung und im Sinne einer finanzamttauglichen Buchführung gefährlich sein. Demgegenüber müsste man bei gespeicherten Werten extrem darauf achten und das sicherstellen, dass diese wie auch alle Werte, die zur Berechnung herangezogen wurden, nicht geändert werden können. Korrekturen sollten dann ausschließlich über zusätzliche Korrekturbuchungen erfolgen.
In beiden Richtungen sollte man nicht leichtfertig sein.

Also Antwort auf die Frage: Es kommt darauf an. Bei einem Onlineshop könntest Du ja alle genannten Bereiche streifen.