Какую схему базы данных я могу использовать для сохранения различных типов платежных данных?

Question

У меня есть система, которая создает заказ, и этот заказ может быть выставлен на собственный счет, отправлен наложенным платежом (COD) или списан с кредитной карты.Я создал следующие таблицы:

ЗАКАЗЫ
номер заказа
billingoption_id

БИЛЛИНГОПЦИИ
billingoption_id

Я не уверен, как следует построить следующую таблицу для данных о выставлении счетов.Должен ли я построить отдельную таблицу для каждого типа варианта выставления счетов (т.ХПК, кредитные карты и домашний счет)?Тогда будет ли у меня еще один столбец внешнего ключа в таблице «Заказы», ​​который будет ссылаться на запись платежных данных?

Answer 1

Вы можете сделать это любым способом:большой сигнал billingoptions таблица, в которой есть поля, охватывающие все типы, с NULL для полей, которые не относятся к данному типу, или группа дочерних таблиц, которые «отходят» от родительского billingoptions стол.Оба имеют свои преимущества и недостатки.

За большой гудящий стол,

• Приятно, что на все данные можно легко ссылаться в одной таблице.
• Отслеживание зависимостей внешних ключей и выполнение обновлений или вставок эффективно.
• НО вам необходимо изменить структуру таблицы, чтобы добавить новые параметры выставления счетов в будущем, и существует вероятность сохранения недопустимых комбинаций данных (например, как тип кредитной карты, так и флаг COD, установленный в одной и той же записи).

Для маленьких детских столиков

• Приятно, что данные секционированы и точно отражают структуру объектов вашей программы.
• Приятно, что вы можете добавлять новые варианты оплаты или изменять существующие, не беспокоясь о том, что это повлияет на другие.
• Отношения ОЧЕНЬ явные.Вы не можете случайно связать депозит с другим депозитом, поскольку внешний ключ потребует, чтобы он был связан с одобрением.
• НО в конечном итоге вы вводите в дизайн множество таблиц, которые требуют большого количества соединений JOIN, могут быть утомительны для навигации и не так эффективны, когда дело доходит до вставок и обновлений.

На работе мы стали использовать маленькие детские столики.Это выглядит примерно так:

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

Все типы платежей имеют три общие таблицы, связанные с транзакциями:

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)

Все наши способы оплаты (кредитная карта, PayPal, Google Checkout, чек, наличные, кредит магазина и денежный перевод) абстрагированы, чтобы вписаться в метафору «Утверждение -> Депозит -> Возврат», а пользовательский интерфейс вызывает те же методы для а IPayment и IPaymentProcessor интерфейсы с разными реализациями (CybersourcePaymentProcessor, PayPalPaymentProcessor, и т. д).Абстракция довольно хорошо работала за последние полтора года для этих разрозненных методов, хотя иногда графический интерфейс отображает пользователю различную формулировку (например, вместо «Утвердить» и «Оплата» будет написано «Авторизовать» и «Оплатить»). «Депозит» для платежей по кредитной карте, а экран ввода наличных одним махом выполняет этап «Одобрить/Внести».)

Надеюсь, это имеет смысл.Похоже, что вы на самом деле не храните платежную информацию, но полезно подумать о том, где эти вещи могут оказаться.

Answer 2

Сосредоточьтесь на вещах.Реальные вещи.Сначала постарайтесь описывать вещи просто, прямо и на естественном языке.

Затем, когда вы попросите рекомендации по проектированию, вы можете предоставить определения.В некоторых случаях сам процесс написания определений приведет к кристаллизации дизайна.

Заказы это вещи.Каковы атрибуты заказа?Клиент, Продукт, Варианты оплаты/выставления счетов.

Варианты оплаты это (почти) вещи.Вы, видимо, можете их определить и идентифицировать.(Я не уверен, что смогу.Судя по вашему вопросу, вы можете это сделать.Но без краткого описания, состоящего из одного предложения, я не понимаю, что происходит с Billion Options.

Что такое «Данные по выставлению счетов?» Что это за вещи?Какими атрибутами (или свойствами) он обладает?

Как «Платежные данные» связаны с Заказом?Как это связано с опцией выставления счетов?

Не стесняйтесь обновлять вопрос, добавляя определения для каждой вещи.