Frage zum Entwurf von Datenbanktabellen

Erstens Datenbankanfänger hier. Ich versuche, ein System für die Verarbeitung von Kundenaufträgen in Bestellungen zu erstellen und dann die Bestellung in Versandbehälter aufzuteilen. Das System muss in der Lage sein, eine Kundenauftragsposition in zwei oder mehr Bestellungen und eine Bestellposition in zwei oder mehr Versandbehälter aufzuteilen.

Es wird einige (viele) Anpassungen geben, bei denen eine Kundenauftragsposition, sobald sie aufgeteilt und in mehrere Bestellungen aufgeteilt wurde, später möglicherweise anders aufgeteilt wird. Dies gilt auch, wenn eine Bestellposition zu Versandbehältern verarbeitet wird. Ich kann für mein ganzes Leben nicht wissen, wie ich mit dieser Operation am besten umgehen soll.

Wenn es hilft, sind hier die Tabellen, die ich bisher habe, wobei einige Details der Kürze halber ausgeschlossen sind:

CREATE TABLE PurchaseOrder (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    PurchaseOrderNumber VARCHAR(15) UNIQUE,

    PRIMARY KEY(Id)
);  

CREATE TABLE Container (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    ContainerName VARCHAR(20) UNIQUE,
    PurchaseOrderId INTEGER UNSIGNED,

    PRIMARY KEY(Id),
    FOREIGN KEY(PurchaseOrderId) REFERENCES PurchaseOrder(Id),
);

CREATE TABLE SalesOrder (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    ClientId INTEGER UNSIGNED,
    SalesOrderNumber VARCHAR(10),

    PRIMARY KEY(Id),
    FOREIGN KEY(ClientId) REFERENCES Client(Id)
);

CREATE TABLE SalesOrderLineItem (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    SalesOrderId INTEGER UNSIGNED,
    ProductId INTEGER UNSIGNED,
    Qty INTEGER,
    Price DECIMAL(5,2),
    Cost DECIMAL(5,2),

    PRIMARY KEY(Id),
    FOREIGN KEY(SalesOrderId) REFERENCES SalesOrder(Id),
    FOREIGN KEY(ProductId) REFERENCES Product(Id)
);

CREATE TABLE PurchaseOrderLineItem (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    PurchaseOrderId INTEGER UNSIGNED,
    SalesOrderId INTEGER UNSIGNED,
    ProductId INTEGER UNSIGNED,
    ClientId INTEGER UNSIGNED,
    MfgId INTEGER UNSIGNED,

    PRIMARY KEY(Id),
    FOREIGN KEY(PurchaseOrderId) REFERENCES PurchaseOrder(Id),
    FOREIGN KEY(SalesOrderId) REFERENCES SalesOrder(Id),
    FOREIGN KEY(ProductId) REFERENCES SalesOrder(Id),
    FOREIGN KEY(ClientId) REFERENCES Client(Id),
    FOREIGN KEY(MfgId) REFERENCES Mfg(Id)
);

Ich denke darüber nach, zusätzliche Zuordnungstabellen zwischen Kundenauftragsposition und Bestellungen sowie für Bestellposition und Container zu erstellen, um diese Art der Aufteilung von Rücken und Schaum zu verfolgen.

Hilfe geschätzt!

Seien Sie im Allgemeinen sparsam mit automatisch generierten Schlüsseln. Wenn Sie einen für den Benutzer benötigen , OK, aber Sie sollten den natürlichen Schlüssel trotzdem erzwingen.

Zum Beispiel haben Sie PurchaseOrder. Es verfügt über einen eindeutigen Schlüssel, der extern bereitgestellt wird. benutze es. Das Hinzufügen eines eigenen automatisch generierten Werts erhöht die Komplexität und nichts anderes.

Ebenso ist SalesOrderLineItem.Id in der gesamten Tabelle eindeutig. Möchten Sie nicht lieber Zeile 1, 2, 3 als 62783444, 62783445, 62783446 sehen? Das macht den Primärschlüssel SaleOrderID, LineItem (anstelle von Id). Gleiches gilt für PurchaseOrderLineItem, das dann den Schlüssel PurchaseOrder LineItem erhält.

Sie erwähnen einige Male "Aufteilen"; Ich nehme an, Sie meinen, eine bestimmte Verkaufsmenge kann auf mehrere Bestellungen und Versandaufträge aufgeteilt werden. Widerstehen Sie der Versuchung (falls es dazu kommt), einen Auslöser zu verwenden, um die Beziehung zu erzwingen, dass beispielsweise die versendete Gesamtsumme nicht höher ist als bestellt. Diese Art von Frage kann in SQL implementiert werden und sollte es sein, jedoch nicht als Einschränkung der referenziellen Integrität. Schreiben Sie eine gespeicherte Prozedur, um zu überprüfen, ob die Bestellung "in Grenzen" ist, und rufen Sie sie zu gegebener Zeit aus Ihrer Anwendung auf. Dies ermöglicht reale anomale Situationen wie verlorene Sendungen und verpfuschte Bestellungen.

Davon abgesehen scheinen Sie für 3NF zu fotografieren, was ein guter Ort ist. Wenn Sie weiterhin die 1: n-Beziehungen befolgen, um Tabellen zu definieren und Einschränkungen konsequent durchzusetzen, erhalten Sie wahrscheinlich ein solides Design.

CREATE TABLE PurchaseOrderLineItem (
    Id INTEGER UNSIGNED UNIQUE NOT NULL AUTO_INCREMENT,
    PurchaseOrderId INTEGER UNSIGNED,
    SalesOrderLineItemId INTEGER UNSIGNED,
    SubQty INTEGER UNSIGNED,
    ContainerID INTEGER UNSIGNED,
    ClientId INTEGER UNSIGNED,
    MfgId INTEGER UNSIGNED,

    PRIMARY KEY(Id),
    FOREIGN KEY(PurchaseOrderId) REFERENCES PurchaseOrder(Id),
    FOREIGN KEY(SalesOrderLineItemId) REFERENCES SalesOrderLineItem(Id),
    FOREIGN KEY(ContainerID) REFERENCES Container(Id),
    FOREIGN KEY(ClientId) REFERENCES Client(Id),
    FOREIGN KEY(MfgId) REFERENCES Mfg(Id)
);

Durch die Verknüpfung mit dem SalesOrderLineItem können Sie für jede Kundenauftragsposition mehrere Bestellpositionen in verschiedenen Containern haben.

Die Untermenge kann beispielsweise 25 in vier PurchaseOrderLineItems und die Gesamtmenge von 100 im SalesOrderLineItem sein.