付款表设计

Question

我有2张付款和付款方式。但是，根据付款方式，某些卡详细信息将不会被存储，并且可能会有一些额外的详细信息。因此存储的卡详细信息取决于付款方式 - 例如使用电汇。设计这个的最佳方法是什么？

+--------------+
| Payments     | 
+--------------+
| CardDetails  |
| Amount       |
| OtherDetails |
+--------------+

+---------------+
| PaymentMethods|
+---------------+
| Id            |
| Type          |
+---------------+

Answer 1

您正在处理Supertype \ Subtype问题。所有付款都有一些共同点（至少是ID和类型），但每种类型都有一些独特的属性。您可以通过多种方式对此场景进行建模，每种方式都有利有弊。

'经典'解决方案是将超类型放在一个表（付款）中，并为每个子类型（付款方式）创建单独的表。超类型表与每个子类型表之间存在1：1的关系。

示例，超类型表：

  

付款（ PaymentID ，PaymentMethodID，日期，用户ID ...）

亚型：

  

CreditCardPayment（ PaymentID ，CardNumber，....）

     

PayPalPayment（ PaymentID ，SecurityCode，...）

     

WireTransfer（ PaymentID ，AccountNumber，...）

创建付款时，您在付款中创建记录并在一个事务中以一个子类型记录。这种实现方式很好，因为它是规范化的，可以很容易地扩展和防错。但遗憾的是，它非常冗长，需要更多的努力才能解除规范化解决方案。

反规范化解决方案是创建一个付款表并为所有付款方式添加一堆列。创建新付款时，大多数列都为空，只有应用程序逻辑知道应该定义哪些列。这个解决方案在实现上要简单得多，但是存在明显的问题。

特殊情况有更多选择，但我认为它们对支付系统来说太过分了。所以这是你的电话，选择什么。作为一个DB人，我更喜欢第一个选择。