Quel schéma de base de données puis-je utiliser pour enregistrer différents types de données de facturation?

Question

J'ai un système qui crée une commande et cette commande peut être facturée sur un compte client, envoyée contre paiement ou sur une carte de crédit. J'ai créé les tableaux suivants:

COMMANDES
order_id
billingoption_id

OPTIONS DE FACTURATION
billingoption_id

Je ne sais pas comment la table suivante devrait être construite pour les données de facturation. Devrais-je créer un tableau séparé pour chaque type d’option de facturation (c.-à-d. Contre remboursement, cartes de crédit et compte maison)? Puis-je avoir une autre colonne de clé étrangère dans la table Commandes qui ferait référence à un enregistrement pour les données de facturation?

Answer 1

Vous pouvez le faire dans les deux sens: une grande table billingoptions qui honore tous les types, avec des valeurs NULL pour les champs qui ne s'appliquent pas à un type donné, ou un groupe de Des tables pour bébé qui "démarrent" d'une table billingoptions parent. Les deux ont leurs avantages et leurs inconvénients.

Pour la grande table de klaxon,

• C'est bien que toutes les données puissent être facilement référencées dans une seule table.
• Le suivi des dépendances de clé étrangère et l'exécution de mises à jour ou d'insertions sont efficaces.
• MAIS vous devez modifier la structure de la table pour ajouter de nouvelles options de facturation. Il est possible que des combinaisons de données non valides soient stockées (par exemple, un type de carte de crédit et un indicateur COD sont définis dans le même enregistrement. ).

Pour les petites tables pour bébé,

• C'est bien que les données soient partitionnées et reflètent la structure d'objet de votre programme.
• Il est bien que vous puissiez ajouter de nouvelles options de paiement ou modifier celles qui existent sans vous soucier des autres.
• Les relations sont TRES explicites. Vous ne pouvez pas lier accidentellement un dépôt à un autre, car la clé étrangère nécessitera un lien avec une approbation.
• MAIS vous introduisez beaucoup de tables dans la conception, qui nécessitent beaucoup de jointures, peuvent être difficiles à naviguer et ne sont pas aussi efficaces en ce qui concerne les insertions et les mises à jour.

Au travail, nous avons fini par aller avec de petites tables pour bébé. Cela ressemble à quelque chose comme ça:

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....

Tous les types de paiement partagent trois tables liées à des transactions:

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)

Tous nos modes de paiement (carte de crédit, PayPal, Google Checkout, chèque, espèces, crédit en magasin et mandat) sont extraits pour correspondre à cette approbation - > Dépôt - > Métaphore de remboursement et l'interface utilisateur appelle les mêmes méthodes sur les interfaces IPayment et IPaymentProcessor avec des implémentations différentes ( CybersourcePaymentProcessor , PayPalPaymentProcessor , etc). L'abstraction a bien fonctionné au cours des 18 derniers mois avec ces méthodes disparates, bien que parfois l'interface graphique affiche un verbiage différent pour l'utilisateur (par exemple, il sera écrit "Autoriser" et "Charger" au lieu de " Approuvez "et" Dépôt "pour les paiements par carte de crédit et l'écran de saisie des espèces effectue l'étape Approbation / Dépôt en une fois.)

J'espère que cela a du sens. On dirait que vous ne stockez pas les informations de paiement, mais il est utile de penser à où ces choses peuvent aboutir.

Answer 2

Concentrez-vous sur les choses. Des choses réelles. Essayez de décrire les choses simplement, directement et d'abord en langage naturel.

Ensuite, lorsque vous demandez des conseils de conception, vous pouvez fournir des définitions. Dans certains cas, le fait d’écrire des définitions fera cristalliser le dessin.

Les

commandes sont des choses. Quels sont les attributs d'une commande? Options client, produit, paiement / facturation.

Les

Options de facturation sont (presque) des choses. Vous pouvez apparemment les définir et les identifier. (Je ne suis pas sûr de pouvoir le faire. D'après votre question, il semblerait que vous puissiez le faire. Mais sans résumé en une phrase, je ne suis pas sûr de ce qui se passe avec Billion Options.

Qu'est-ce qu'une "donnée de facturation?" Quel genre de chose est-ce? Quels sont ses attributs (ou propriétés)?

Comment fonctionne un " données de facturation " se rapporter à un ordre? Quel est le lien avec une option de facturation?

N'hésitez pas à mettre à jour la question avec des définitions pour chaque élément.