design-patterns - learning - patron factory java

¿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 del hogar, se le puede enviar en efectivo contra reembolso (COD) o se puede cargar en una tarjeta de crédito. Creé las siguientes tablas:

PEDIDOS
Solicitar ID
billingoption_id

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, COD, tarjetas de crédito y cuenta de la casa)? Entonces, ¿tendría otra columna de clave externa en la tabla Pedidos que se refiera a un registro de los datos de facturación?

Answer 1

Centrarse en las cosas Cosas reales Trate de describir las cosas de manera simple, directa y en lenguaje natural primero.

Luego, cuando solicite una guía de diseño, puede proporcionar definiciones. En algunos casos, el hecho de escribir definiciones hará que el diseño cristalice.

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

Las opciones de facturación son (casi) cosas. Al parecer, puede definirlos e identificarlos. (No estoy seguro de poder. De tu pregunta, parece que podrías. Pero sin un resumen de una oración, no estoy seguro de lo que está pasando con Billion Options.

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

¿Cómo se relacionan los "datos de facturación" con un pedido? ¿Cómo se relaciona con una opción de facturación?

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

Answer 2

Puedes hacerlo de cualquier manera: una gran tabla de billingoptions bocina que tiene campos que abarca todos los tipos, con NULL para campos que no se aplican a un tipo determinado, o un grupo de tablas de bebés que "destacan" de un padre mesa de billingoptions Ambos tienen sus ventajas y desventajas.

Para la gran mesa de bocina,

• Es bueno que todos los datos se puedan referenciar fácilmente en una sola tabla.
• El seguimiento de las dependencias de claves externas y la realización de actualizaciones o inserciones es eficiente.
• PERO necesita 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 inválidas de datos (por ejemplo, tanto un tipo de tarjeta de crédito como un indicador de COD se establecen en el mismo registro).

Para las pequeñas mesas de bebé,

• Es bueno que los datos estén particionados y reflejen la estructura de objetos de su programa.
• Es bueno que pueda agregar nuevas opciones de pago o modificar las existentes sin preocuparse por afectar a los 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 un montón de JOINs, 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 ve algo como 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 la transacción:

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 abstraen para que quepan en esta aprobación -> Depositar -> Reembolsar metáfora, y la IU llama a los mismos métodos en un IPayment e IPaymentProcessor interactúa 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á una verborrea diferente para el usuario (por ejemplo, dirá "Autorizar" y "Cargar" en lugar de "Aprobar" y "Depositar" para pagos con tarjeta de crédito, y la pantalla para ingresar efectivo realiza el paso Aprobar / Depositar 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.