Datenbankentwurf?

Question

Wir haben ein Sales-bezogenes Projekt.

Jetzt führen wir den Lagerbestand der Produkte in einer separaten Tabelle mit dem Namen Stock. Zum Zeitpunkt des Verkaufs, Verkauf-Rückgabe, Kauf und Rückgabe wird die Lagerliste aktualisiert. Es funktioniert gut, aber während wir einen Verkauf oder Kauf löschen oder ändern, ist es schwieriger, den Bestand zu erhalten.

Ich sagte meinem Chef, dass wir den Bestand nicht in einer separaten Tabelle behalten wollen, sondern eine Funktion schreiben, um den Bestand aus den zugehörigen Tabellen zu berechnen (sales, purchase, ...). Wann immer der Benutzer den Bestand wissen möchte, ruft er die Funktion auf, um den Bestand sehr einfach zu erhalten. Dabei müssen wir nicht über die Lagerhaltung nachdenken. Ich denke, es ist eine gute Idee.

Aber er sagte mir, dass, wenn viele Datensätze kommen, die Funktion mehr Zeit zur Ausführung braucht und es die Effizienz der Software reduziert. Ich weiß nicht, ob das stimmt oder nicht. Eine Sache, die ich weiß, ist, dass es gegen die Normalisierung von DB ist. Wir müssen die berechneten Werte nicht innerhalb oder außerhalb der Tabelle behalten.

Wie könnte ich diese DB entwerfen? Ist ein separater Stock Tisch besser oder nicht?

Answer 1

Es gibt eine ausgezeichnete Studie zu diesem Thema here, von Allen Browne.

Answer 2

Im Allgemeinen ist es am besten, eine normalisierte Datenbank zu haben. Wenn Sie Datenduplikation haben und die Software eines Tages nicht ganz so funktioniert, wie sie sollte, dann könnten Sie mit inkonsistenten Daten enden, was für niemanden gut ist.

Für die meisten Zwecke können Berechnungen so effizient durchgeführt werden, dass Sie sie mit den Rohdaten ausführen können, wie Sie vorschlagen. Wenn dies für Ihr Projekt ein Skalierbarkeitsproblem darstellt, wäre es vielleicht am besten, eine Tabelle mit den berechneten Werten zu haben. Dies würde niemals als Originaldaten behandelt werden und könnte zu jedem Zeitpunkt neu berechnet werden. Dann sind Ihre Daten sicher und Ihre Berechnungen sind schnell.

Die andere Alternative, abhängig von Ihrem DBMS, ist die Betrachtung einer Ansicht.

Answer 3

Was ist der Inhalt Ihrer Lagerliste? Haben Sie verschiedene Lager, in denen das gleiche Produkt gelagert werden kann? Wenn es nur eine einzige Aktie gibt, würde ich von einer separaten Tabelle oder einer berechneten Aktie abraten. Die Berechnung des Bestands kann sehr komplex und zeitraubend sein, insbesondere wenn Sie häufiger Abfragen durchführen als Aktualisierungen durchführen. Sie sollten dann den Lagerbestand Teil Ihrer Produkttabelle machen.

Answer 4

Im Allgemeinen möchten Sie mehr Normalisierung, um die Datenintegrität zu erhalten, und dies optimiert auch die Datenaktualisierung (Sie müssen nicht dieselbe Information an mehr als einer Stelle aktualisieren). Die einzige wirkliche Ausnahme ist, wenn Ihre Datenbank hauptsächlich für das Reporting verwendet wird und nur gelegentlich aktualisiert wird. Die Kosten für die Aktualisierung an mehreren verschiedenen Orten (weil Sie denormalisiert werden) werden dadurch bezahlt, dass Sie beim Berichten keine Informationen von vielen verschiedenen Orten abrufen müssen.

Wenn Ihre Datenbank für Transaktionen schnell sein muss (Aktualisierung), und nur gelegentlich berichten, dann normalisieren Sie so viel wie möglich. Es ist auch einfacher, alle Daten auf diese Weise konsistent zu halten. Wenn Sie jedoch nur gelegentlich aktualisieren und hauptsächlich berichten (d. H. Lesen oder einfach Daten aus der Datenbank ziehen), dann könnte Ihr Chef recht haben und es könnte eine bessere Alternative sein, denormalization zu machen. Es ist jedoch komplizierter, Fehlerbedingungen zu handhaben und die Datenintegrität zu wahren (Sie müssen mehr darüber nachdenken, was eine "logische Transaktion" ist, und wann alle bisher gemachten Aktualisierungen rückgängig gemacht werden müssen, wenn etwas schief geht).

Answer 5

Haben Sie darüber nachgedacht, Trigger zum Aktualisieren der Lagerliste zu verwenden?

In einer perfekten Welt entspricht die Summe aller Änderungen der aktuellen Anzahl der Artikel auf Lager. In der realen Welt ist die Summe der Änderungen eher ein statistischer Prädiktor für die Anzahl der auf Lager befindlichen Artikel. Wenn Sie die reale Welt perfekt machen wollen, müssen Sie alle möglichen Änderungen in dieser Zahl berücksichtigen. Neben dem Kauf und Verkauf benötigen Sie Transaktionsarten für den Anfangsbestand, für Diebstahl, Naturkatastrophen, Spenden an das Rote Kreuz usw. Sie benötigen Dummy-Transaktionen, um die Anzahl zu korrigieren, wenn der Prädiktor und die tatsächliche Anzahl der Elemente für unvorhergesehene Abweichungen abweichen Grund. All dies wird Ihre Transaktionstabellen überladen.

Das Leistungsargument Ihres Chefs ist ebenfalls gültig. Jedes Mal, wenn Sie die Anzahl der Artikel auf Lager benötigen, müssen Sie alle Transaktionen summieren. Wenn Sie viele davon haben, kann dies zu einem Leistungsengpass werden, selbst wenn Sie die Transaktionstabelle ordnungsgemäß indizieren, damit Sie die Summe aus dem Index herausholen können.

Und nicht völlig zustimmen auf der Tabelle widerspricht Normalisierung. Die Anzahl der Artikel, die Sie gerade auf Lager haben, und die Anzahl der Artikel, die gekauft oder verkauft werden, sind konzeptionell nicht gleich, sie sind unterschiedliche Nummern, die zufällig durch die Geschäftsregel verbunden sind, die Ihr Unternehmen kauft und verkauft (eher als sie herzustellen und an das Rote Kreuz zu spenden, und wie oben beschrieben, sind sie nur in einer perfekten Welt perfekt korreliert.