Was ist ein vorgeschlagenes Datenbankschema für Bestell-/Rechnungsinformationen?

Ich muss einige Änderungen an einem E-Commerce-System vornehmen, um einige zusätzliche Informationen hinzuzufügen, und wollte die Gelegenheit nutzen, möglicherweise einige Verbesserungen vorzunehmen und es flexibler zu gestalten. Wenn ein Kunde eine Bestellung aufgibt, müssen wir mehrere Informationen mit jedem bestellten Artikel speichern. zum Beispiel der Produktpreis, der Versandpreis, die erhobene Steuer, alle vorgenommenen Anpassungen.Was ist ein vorgeschlagenes Datenbankschema für Bestell-/Rechnungsinformationen?

ich diskutieren werde, wenn diese Felder diskret gespeichert werden sollen, wie zum Beispiel (vereinfachtes Beispiel):

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 
    Price 
    Shipping 
    Handling  
    SalesTax 
    Adjustment

Zum Beispiel könnte ich dann den Gesamtpreis berechnen die Kunden bezahlt:

SELECT Qty*(Price+Shipping+Handling+SalesTax) As TotalCollected FROM ORDER_LINE_ITEM

oder wenn ich soll eine indirekte Struktur verwenden:

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 

ORDER_LINE_ITEM_ENTRIES 
    OrderLineItemEntryID 
    OrderLineItemID 
    EntryType 
    Value

Zum Beispiel:

1 | 1 | Price  | $10 
2 | 1 | Shipping | $5 
3 | 1 | Handling | $1 
4 | 1 | SalesTax | $1 
5 | 1 | Adjustment | -$3.50

Der Vorteil dabei ist, dass ich später weitere Informationen speichern kann, ohne das Tabellenschema zu ändern. Das Abrufen der Informationen und das Ausführen von Berichten wird jedoch komplizierter und langsamer.

Gibt es eine bewährte Methode zum Speichern dieser Informationen in Bestell-/Rechnungsdatenbanken?

Vielen Dank im Voraus,

Dan

Quelle

2012-07-21 Dan C

Was haben Sie am Ende ausgewählt? –

Ich landete die mehr denormalisierte Struktur, wo ich Preis, Versand, Handhabung, etc als Teil jeder Werbebuchung und TotalPrice, TotalShipping, TotalHandling usw. als Teil der Bestellung habe. Die Bestellsummen werden von der Business-Schicht immer dann neu berechnet, wenn ein Wert geändert wird (was selten vorkommt). Dies macht es sehr schnell und einfach, Berichte abzufragen (was häufig vorkommt), ohne dass die Verbraucher der Daten die Struktur kennen müssen. –

Ich würde einen gemischten Ansatz tun, die beide:

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 
    Price 
    Shipping 
    Handling  
    SalesTax 
    Adjustment 
    Extras 

ORDER_LINE_ITEM_ENTRIES 
    OrderLineItemEntryID 
    OrderLineItemID 
    EntryType 
    Value

Und dann

SELECT Qty*(Price+Shipping+Handling+SalesTax+Extras) As TotalCollected FROM ORDER_LINE_ITEM

Dann machst du die meiste Zeit mit einer einzigen Tabelle arbeiten können, aber wenn Sie müssen nach den Details eines Artikels suchen (oder neue Dinge hinzufügen, die den Preis beeinflussen), Sie können es tun (mit dem zusätzlichen Feld).

In einem anderen Thema würde ich überlegen, ob alle diese Felder wirklich auf ORDER_LINE_ITEM sein sollten. Ich kenne Ihr Geschäft nicht, aber in den mir bekannten, wird der Versand-, Handling- und sogar Preispreis über die gesamte Bestellung berechnet, nicht nur für einen Artikel (und es ist nicht immer möglich, ihn in getrennte Artikel aufzuteilen). Es ist auch ziemlich üblich, einen "Admin" -Benutzer oder ein Passwort zu haben, der kommen und verkaufen kann, was er will, beliebige Felder für alles eingeben und alle normalen Geschäftsregeln ignorieren. So könnte man bedenkt, etwas zu tun, wie:

ORDER_LINE_ITEM 
    OrderLineItemID 
    OrderId 
    ProductID 
    Qty 

ORDER 
    OrderId 
    ItemsTotalPrice 
    Shipping 
    Handling 
    SalesTaxes 
    Adjusment 
    FinalPrince

Sie könnten eine Detailtabelle erstellen, um festzulegen, wie die Werte der Ordnung (Steuern, Versand, etc ..) wurden erstellt ...

Im Allgemeinen I Ich habe festgestellt, dass der beste Ansatz darin besteht, eine Entität zu haben, die die letzte Information über die gesamte Reihenfolge (oder Operation) enthält, und dann zusätzliche Untereinheiten, die angeben, wie die "Gesamt" -Werte berechnet wurden.

Quelle

2012-07-21 03:53:31 user1494736

Das ist ein guter Punkt, und unser derzeitiges System hat tatsächlich den Versand, die Handhabung und die Steuer auf der Auftragsebene. Wir erweitern jedoch die Integration mit Drittanbieter-Bestellsystemen wie Amazon und stellen diese Werte für jede Bestellposition bereit. Es würde es einfacher machen, Rückerstattungen und andere Transaktionen zu verwalten, wenn wir diese Werte in einem ähnlichen Format behalten, anstatt sie in der Auftragsebene zu aggregieren. Ich versuche es auf die bestmögliche Weise. –

Konzeptionell ist besser ur zweiter aproach, da tut, um Informationen direkt zu einem Produkt gehört, existiert ein Produkt kann ohne „Versand“, „taxex“, außer, Auf diese Weise speichern Sie weniger Daten und benötigen keine wiederholten Produktinformationen.

ORDERITEM 
    OrderItemID 
    ProductID 
    Qty 

ORDERITEMENTRIES 
    OrderItemID 
    EntryType 
    Value

Quelle

2012-07-21 00:59:48 levi

Danke für die Rückmeldung. Der Produktdatensatz selbst (Name, Beschreibung, aktueller Preis, etc.) würde natürlich in einer separaten Tabelle sein. Mein Beispiel bezieht sich auf eine einzelne Werbebuchung in der Reihenfolge, die uns sagt, welche Produkt-ID gekauft wurde und wie viel der Kunde dafür bezahlt hat. Ich habe die Tabellennamen in meinem Beispiel aktualisiert, um dies besser zu veranschaulichen. –

Ah srry, ich habe es, dann, in diesem Fall, ist besser Ihr erster Ansatz, denn, macht keinen Sinn, dass ein line_item_order existiert ohne einen Preis zum Beispiel, neben dem Preis für die Erweiterung Modell, nur für hat EntryType wie "Variable Attribut ", es lohnt sich nicht. – levi

Sie können einige ziemlich Standard-Datenbank-Designs für häufige Probleme bei Datenbank Antworten finden. Click here für ihre Datenmodelle Seite.

Es gibt mehrere Beispielmodelle, die mit der Fakturierung zu tun haben.

Quelle

2012-07-21 15:07:10

Ausgezeichnete Info. Ich habe nach so etwas gesucht. Obwohl ich nicht weiß, wie "standard" das ist (zB verwenden sie Unterstriche in ihrer Benennung, während ich modernere Designs gesehen habe, die mit MixedCase-Namen gemacht wurden) –

@DanC - Ich würde offen jedes Modell von Database Answers mit einem sehr großen nehmen Salzkorn. Ich habe festgestellt, dass ihre Modelle für reale Anwendungen unpraktisch einfach sind. Es ist gut, sich ein generisches Modell anzusehen, wenn Sie mit einem neuen Design beginnen. Es könnte Ihnen etwas auffallen, an das Sie nicht gedacht haben. Am Ende des Tages sollten Sie Ihr Schema basierend auf Ihren Geschäftsanforderungen und nicht auf dem eines anderen Modells modellieren. –

Ja, die Datenbankantworten machen einen besseren Ausgangspunkt als eine endgültige Lösung. –

Was ist ein vorgeschlagenes Datenbankschema für Bestell-/Rechnungsinformationen?

Antwort

Verwandte Themen