Quale schema di database posso usare per salvare diversi tipi di dati di fatturazione?

Question

Ho un sistema che crea un ordine e quell'ordine può essere addebitato su un conto corrente, inviato in contrassegno o addebitato su una carta di credito. Ho creato le seguenti tabelle:

ORDINI
order_id
billingoption_id

BILLINGOPTIONS
billingoption_id

Non sono sicuro di come debba essere costruita la tabella successiva per i dati di fatturazione. Devo creare una tabella separata per ogni tipo di opzione di fatturazione (ad es. COD, carte di credito e conto corrente)? Quindi avrei un'altra colonna chiave esterna nella tabella Ordini che farebbe riferimento a un record per i dati di fatturazione?

Answer 1

Puoi farlo in entrambi i modi: una grande tabella billingoptions che suona il clacson che ha campi che comprendono tutti i tipi, con valori NULL per i campi che non si applicano a un determinato tipo, o un gruppo di tavolini che "star fuori" di una tabella fatturazione padre. Entrambi hanno i loro vantaggi e svantaggi.

Per il grande tavolo di clacson,

• È bello poter fare facilmente riferimento a tutti i dati in una singola tabella.
• Il monitoraggio delle dipendenze di chiavi esterne e l'esecuzione di aggiornamenti o inserimenti è efficace.
• MA è necessario modificare la struttura della tabella per aggiungere nuove opzioni di fatturazione in futuro e esiste la possibilità di memorizzare combinazioni di dati non valide (ad esempio, sia un tipo di carta di credito che un contrassegno COD vengono impostati nello stesso record ).

Per i tavolini per bambini,

• È bello che i dati siano partizionati e riflettano da vicino la struttura degli oggetti del tuo programma.
• È bello poter aggiungere nuove opzioni di pagamento o modificare quelle esistenti senza preoccuparsi di influire sugli altri.
• Le relazioni sono MOLTO esplicite. Non è possibile collegare accidentalmente un deposito a un altro deposito, poiché la chiave esterna richiederà che sia collegata a un'approvazione.
• MA finisci per introdurre un sacco di tabelle nel design, che richiedono molti JOIN, può essere una seccatura da navigare e non sono efficienti quando si tratta di inserimenti e aggiornamenti.

Al lavoro, abbiamo finito con i tavolini per bambini. Sembra qualcosa del genere:

Table Orders:
--> OrderId PK
--> (Lots of Other Fields)

Table Payments:
--> PaymentId PK
--> OrderId (FK) [There may be more than one payment per order]
--> PaymentType [Restricted field contains values like 
       'PAYPAL' or 'CREDIT', you use this to know which 
       baby table to look up that can contain additional 
       information]

Table PaymentsPayPal:
--> PaymentPayPalId PK
--> PaymentId FK points to Table Payments
--> TransactionNo
--> (Other PayPal specific fields)

Table PaymentsCheck:
--> PaymentCheckId PK
--> PaymentId FK points to Table Payments
--> RoutingNo
--> (Other e-check specific fields)

+ other tables for remaining payment types....

Tutti i tipi di pagamento condividono tre tabelle relative alle transazioni:

Table PaymentApprovals:
--> PaymentApprovalId PK
--> PaymentId FK points to Table Payments
--> Status [Some flag meaning 'Succeeded', 'Failed', 'Reversed', etc]
--> ProcessorMessage [Something the service sent back, like '(M) CVV2 Matched']
--> Amount
--> (Other administrative fields)

Table PaymentDeposits:
--> PaymentDepositId PK
--> PaymentApprovalId FK points to Table PaymentApprovals
--> Status
--> ProcessorMessage
--> Amount
--> (Other administrative fields)

Table PaymentRefunds:
--> PaymentRefundId PK
--> PaymentDepositId FK points to Table PaymentDeposits
--> Status
--> ProcessorMessage
--> Amount
--> (Other administrative fields)

Tutti i nostri metodi di pagamento (carta di credito, PayPal, Google Checkout, assegno, contanti, credito del negozio e vaglia postale) sono astratti per adattarsi a questa approvazione - > Deposito - > Metafora di rimborso e l'interfaccia utente chiama gli stessi metodi su un IPayment e IPaymentProcessor interfacce con implementazioni diverse ( CybersourcePaymentProcessor , PayPalPaymentProcessor , ecc.). L'astrazione ha funzionato abbastanza bene nell'ultimo anno e mezzo attraverso questi metodi disparati, anche se a volte la GUI mostrerà diverse parole d'ordine all'utente (ad esempio, dirà "Autorizza" e "quotata" anziché "quotata" Approva "e" deposito "per i pagamenti con carta di credito e la schermata per l'immissione di contanti esegue la fase di approvazione / deposito in un colpo solo.)

Spero che abbia un senso. Sembra che tu non stia effettivamente memorizzando le informazioni di pagamento, ma è utile pensare a dove possono finire queste cose.

Answer 2

Concentrati sulle cose. Cose reali. Prova a descrivere prima le cose semplicemente, direttamente e in linguaggio naturale.

Quindi, quando chiedi una guida alla progettazione, puoi fornire delle definizioni. In alcuni casi, l'atto di scrivere definizioni renderà il design cristallizzato.

Ordini sono cose. Quali sono gli attributi di un ordine? Opzioni cliente, prodotto, pagamento / fatturazione.

Opzioni di fatturazione sono (quasi) cose. A quanto pare, è possibile definirli e identificarli. (Non sono sicuro che potrei. Dalla tua domanda, sembra che potresti esserne in grado. Ma senza un sommario di una frase, non sono sicuro di cosa stia succedendo con miliardi di opzioni.

Che cos'è un " dati di fatturazione? " Che tipo di cosa è questa? Quali attributi (o proprietà) ha?

Come funziona un " Dati di fatturazione " si riferiscono ad un ordine? Come si collega a un'opzione di fatturazione?

Sentiti libero di aggiornare la domanda con le definizioni per ogni cosa.