Qual è lo schema del database suggerito per le informazioni su ordini/fatture?

Devo apportare alcune modifiche a un sistema di e-commerce per aggiungere alcune informazioni aggiuntive e ho voluto cogliere l'opportunità per apportare alcuni miglioramenti e renderlo più flessibile. Quando un cliente effettua un ordine, dobbiamo memorizzare diverse voci di informazioni con ogni articolo ordinato; ad esempio, il prezzo del prodotto, il prezzo di spedizione, l'imposta riscossa, eventuali rettifiche apportate.Qual è lo schema del database suggerito per le informazioni su ordini/fatture?

sto discutendo se questi campi devono essere conservati in modo discreto, come ad esempio (esempio semplificato):

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 
    Price 
    Shipping 
    Handling  
    SalesTax 
    Adjustment

Per esempio, ho potuto quindi calcolare il prezzo complessivo del cliente ha pagato:

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

O se dovrei usare una struttura più indiretta:

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 

ORDER_LINE_ITEM_ENTRIES 
    OrderLineItemEntryID 
    OrderLineItemID 
    EntryType 
    Value

Ad esempio:

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

Il vantaggio con questo è che posso memorizzare ulteriori informazioni in seguito senza alterare lo schema della tabella. Tuttavia, il recupero delle informazioni e l'esecuzione dei report diventano più complicati e lenti.

Esiste una buona pratica per archiviare queste informazioni nei database di ordini/fatture?

Grazie in anticipo,

Dan

fonte

2012-07-21 Dan C

Cosa hai scelto? –

Ho finito per eseguire la struttura denormalizzata in cui ho il prezzo, la spedizione, la gestione, ecc. Come parte di ciascun elemento pubblicitario e TotalPrice, TotalShipping, TotalHandling, ecc. Come parte dell'odore. I totali dell'ordine vengono ricalcolati dal livello aziendale ogni volta che viene modificato qualsiasi valore (che è raro). Ciò rende molto facile e veloce il recupero dei report (cosa che accade spesso) senza che i consumatori dei dati debbano conoscere la struttura. –

farei un approccio misto, avendo entrambi:

ORDER_LINE_ITEM 
    OrderLineItemID 
    ProductID 
    Qty 
    Price 
    Shipping 
    Handling  
    SalesTax 
    Adjustment 
    Extras 

ORDER_LINE_ITEM_ENTRIES 
    OrderLineItemEntryID 
    OrderLineItemID 
    EntryType 
    Value

e poi facendo

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

Poi si può lavorare il più delle volte con una singola tabella, ma se devi cercare i dettagli di un oggetto (o aggiungere nuove cose che influenzano il prezzo), puoi farlo (usando il campo extra).

In un altro argomento, prenderei in considerazione se tutti quei campi dovrebbero essere effettivamente su ORDER_LINE_ITEM. Non conosco il tuo business, ma in quelli che conosco, la spedizione, la gestione e persino il prezzo sono calcolati sull'intero ordine, non su un solo articolo (e non è sempre possibile dividerlo in articoli separati). È anche abbastanza comune avere un utente o una password "Admin", che può venire a vendere qualsiasi cosa desideri, inserendo campi arbitrari per tutto e ignorando tutte le normali regole aziendali. Così si potrebbe considerare di fare qualcosa di simile:

ORDER_LINE_ITEM 
    OrderLineItemID 
    OrderId 
    ProductID 
    Qty 

ORDER 
    OrderId 
    ItemsTotalPrice 
    Shipping 
    Handling 
    SalesTaxes 
    Adjusment 
    FinalPrince

è possibile creare una tabella di dettaglio per specificare come sono stati creati i valori dell'ordine (tasse, spedizione, ecc ..) ...

In generale, ho Abbiamo trovato che l'approccio migliore è quello di avere un'entità che ha le informazioni finali di tutto l'ordine (o operazione), e quindi ulteriori sub-entità che specificano come sono stati calcolati i valori "totali".

fonte

2012-07-21 03:53:31 user1494736

Questo è un buon punto e il nostro sistema attuale ha effettivamente la spedizione, la gestione e le tasse a livello di ordine. Tuttavia, stiamo espandendo l'integrazione con sistemi di ordini di terze parti, come Amazon, e forniscono tali valori su ciascun articolo dell'ordine. Sarebbe più semplice gestire i rimborsi e altre transazioni se manteniamo questi valori in un formato simile invece di aggregarli nel livello dell'ordine. Sto cercando di farlo nel miglior modo possibile. –

Concettualmente, è meglio ur secondo aproach, in quanto le informazioni ordine doesnt appartengono direttamente a un prodotto, un prodotto esiste senza "spedizione", "taxex", inoltre, in questo modo, stai memorizzando meno dati, non hai bisogno di ripetere le informazioni sul prodotto.

ORDERITEM 
    OrderItemID 
    ProductID 
    Qty 

ORDERITEMENTRIES 
    OrderItemID 
    EntryType 
    Value

fonte

2012-07-21 00:59:48 levi

Grazie per il feedback. Il record del prodotto stesso (nome, descrizione, prezzo corrente, ecc.) Sarebbe ovviamente in una tabella separata. Il mio esempio è per un singolo elemento pubblicitario nell'ordine che ci dice quale ID prodotto è stato acquistato e quanto il cliente ha pagato per questo. Ho aggiornato i nomi delle tabelle nel mio esempio per illustrare meglio questo. –

Ah srry, ho capito, allora, in questo caso, è meglio il tuo primo approccio, perché, non ha senso che un line_item_order esista senza un prezzo per esempio, oltre a pagare il prezzo per estendere il modello, solo per EntryType come "variabile attributo ", non vale. – levi

È possibile trovare diversi progetti di database standard per problemi comuni a Database Answers. Click here per la loro pagina dei modelli di dati.

Ci sono diversi modelli di esempio che hanno a che fare con la fatturazione.

fonte

2012-07-21 15:07:10

Informazioni eccellenti. Ho cercato qualcosa di simile. Anche se non so quanto questo sia "standard" (ad es. Usano i caratteri di sottolineatura nella loro denominazione, mentre ho visto più disegni moderni fatti usando i nomi di MixedCase) –

@DanC - Prenderò francamente qualsiasi modello da Database Answers con un molto grande granello di sale. Ho trovato che i loro modelli tendono ad essere in modo praticamente semplice per le applicazioni del mondo reale. È bello dare un'occhiata a un modello generico quando si inizia un nuovo progetto. Potrebbe portare alla tua attenzione qualcosa a cui non hai pensato. Alla fine della giornata dovresti modellare il tuo schema in base alle tue esigenze di business non su quelle di qualcun altro. –

Sì, le risposte al database rappresentano un punto di partenza migliore rispetto a una soluzione finale. –

Qual è lo schema del database suggerito per le informazioni su ordini/fatture?

risposta

Problemi correlati