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

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

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

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

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

Что такое «платежные данные»? Что это за штука? Какие атрибуты (или свойства) у него есть?

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

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

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

Для большого гудящего стола,

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

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

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

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

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 и т. д.). Абстракция работала довольно хорошо в течение последних полутора лет для этих разрозненных методов, хотя иногда в графическом интерфейсе пользователя отображается разное словоблудие (например, вместо «Утвердить» и «Депозит» для платежей по кредитной карте, а экран для ввода наличных выполняет этап Утверждение / Депозит одним махом.)

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