¿Qué esquema de base de datos puedo usar para guardar diferentes tipos de datos de facturación?

Question

Tengo un sistema que crea un pedido y ese pedido se puede facturar a una cuenta propia, enviar contra reembolso (COD) o cargar a una tarjeta de crédito. He creado las siguientes tablas:

PEDIDOS
order_id
billingoption_id

OPCIONES DE FACTURACIÓN
billingoption_id

No estoy seguro de cómo se debe construir la siguiente tabla para los datos de facturación. ¿Debo crear una tabla separada para cada tipo de opción de facturación (es decir, contra reembolso, tarjetas de crédito y cuenta propia)? Entonces, ¿tendría otra columna de clave externa en la tabla Pedidos que se referiría a un registro de los datos de facturación?

Answer 1

Puede hacerlo de cualquier manera: una gran tabla de bocina billingoptions que tiene campos que abarcan todos los tipos, con NULL para campos que no se aplican a un tipo determinado, o un montón de Mesas de bebé que `` comienzan '' de una tabla padre billingoptions . Ambos tienen sus ventajas y desventajas.

Para la gran mesa de bocina,

• Es bueno que todos los datos puedan ser referenciados fácilmente en una sola tabla.
• El seguimiento de dependencias de claves externas y la realización de actualizaciones o inserciones es eficiente.
• PERO debe modificar la estructura de la tabla para agregar nuevas opciones de facturación en el futuro, y existe la posibilidad de que se almacenen combinaciones no válidas de datos (por ejemplo, tanto un tipo de tarjeta de crédito como un indicador COD se establezcan en el mismo registro ).

Para las mesitas de bebé,

• Es bueno que los datos estén particionados y reflejen la estructura de objetos de su programa de cerca.
• Es bueno que pueda agregar nuevas opciones de pago o alterar las existentes sin preocuparse de afectar a las demás.
• Las relaciones son MUY explícitas. No puede vincular accidentalmente un depósito con otro depósito, ya que la clave externa requerirá que se vincule con una aprobación.
• PERO terminas introduciendo muchas tablas en el diseño, que requieren muchas uniones, puede ser difícil de navegar y no son tan eficientes cuando se trata de inserciones y actualizaciones.

En el trabajo, terminamos yendo con pequeñas mesas para bebés. Se parece a esto:

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

Todos los tipos de pago comparten tres tablas relacionadas con las transacciones:

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)

Todos nuestros métodos de pago (tarjeta de crédito, PayPal, Google Checkout, cheque, efectivo, crédito de la tienda y giro postal) se resumen para ajustarse a esta aprobación - > Depósito - > Metáfora de reembolso, y la IU llama a los mismos métodos en un IPayment y IPaymentProcessor interfaces con diferentes implementaciones ( CybersourcePaymentProcessor , PayPalPaymentProcessor , etc.). La abstracción ha funcionado bastante bien durante el último año y medio a través de estos métodos dispares, aunque a veces la GUI mostrará verborrea diferente al usuario (por ejemplo, dirá "Autorizar" y "Cargar" en lugar de ""). Aprobar " y " Depósito " para pagos con tarjeta de crédito, y la pantalla para ingresar efectivo realiza el paso Aprobar / Depósito de una sola vez).

Espero que tenga sentido. Parece que en realidad no está almacenando información de pago, pero es útil pensar dónde pueden terminar estas cosas.

Answer 2

Céntrate en las cosas. Cosas reales Intente describir las cosas de manera simple, directa y en lenguaje natural primero.

Luego, cuando solicite orientación de diseño, puede proporcionar definiciones. En algunos casos, el acto de escribir definiciones hará que el diseño se cristalice.

Los

pedidos son cosas. ¿Cuáles son los atributos de un pedido? Cliente, producto, opciones de pago / facturación.

Las

Opciones de facturación son (casi) cosas. Puede, al parecer, definirlos e identificarlos. (No estoy seguro de poder hacerlo. Según su pregunta, parece que podría hacerlo. Pero sin un resumen de una oración, no estoy seguro de lo que está sucediendo con Billion Options.

¿Qué es un " datos de facturación? " ¿Qué clase de cosa es esta? ¿Qué atributos (o propiedades) tiene?

¿Cómo funciona un " Datos de facturación " relacionarse con una orden? ¿Cómo se relaciona con una opción de facturación?

Siéntase libre de actualizar la pregunta con definiciones para cada cosa.