Какую схему базы данных я могу использовать для сохранения различных типов платежных данных?
-
10-07-2019 - |
Вопрос
У меня есть система, которая создает заказ, и этот заказ может быть выставлен на собственный счет, отправлен наложенным платежом (COD) или списан с кредитной карты.Я создал следующие таблицы:
ЗАКАЗЫ
номер заказа
billingoption_id
БИЛЛИНГОПЦИИ
billingoption_id
Я не уверен, как следует построить следующую таблицу для данных о выставлении счетов.Должен ли я построить отдельную таблицу для каждого типа варианта выставления счетов (т.ХПК, кредитные карты и домашний счет)?Тогда будет ли у меня еще один столбец внешнего ключа в таблице «Заказы», который будет ссылаться на запись платежных данных?
Решение
Вы можете сделать это любым способом:большой сигнал 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
, и т. д).Абстракция довольно хорошо работала за последние полтора года для этих разрозненных методов, хотя иногда графический интерфейс отображает пользователю различную формулировку (например, вместо «Утвердить» и «Оплата» будет написано «Авторизовать» и «Оплатить»). «Депозит» для платежей по кредитной карте, а экран ввода наличных одним махом выполняет этап «Одобрить/Внести».)
Надеюсь, это имеет смысл.Похоже, что вы на самом деле не храните платежную информацию, но полезно подумать о том, где эти вещи могут оказаться.
Другие советы
Сосредоточьтесь на вещах.Реальные вещи.Сначала постарайтесь описывать вещи просто, прямо и на естественном языке.
Затем, когда вы попросите рекомендации по проектированию, вы можете предоставить определения.В некоторых случаях сам процесс написания определений приведет к кристаллизации дизайна.
Заказы это вещи.Каковы атрибуты заказа?Клиент, Продукт, Варианты оплаты/выставления счетов.
Варианты оплаты это (почти) вещи.Вы, видимо, можете их определить и идентифицировать.(Я не уверен, что смогу.Судя по вашему вопросу, вы можете это сделать.Но без краткого описания, состоящего из одного предложения, я не понимаю, что происходит с Billion Options.
Что такое «Данные по выставлению счетов?» Что это за вещи?Какими атрибутами (или свойствами) он обладает?
Как «Платежные данные» связаны с Заказом?Как это связано с опцией выставления счетов?
Не стесняйтесь обновлять вопрос, добавляя определения для каждой вещи.