付款表设计

Question

我有 2 个表 Payments 和 PaymentMethods。但是，根据付款方式，一些银行卡详细信息不会被存储，而一些额外的详细信息可能会被存储。因此，存储的卡详细信息取决于付款方式 - 例如电汇。最好的设计方法是什么？

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

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

Answer 1

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

'Classical' 解决方案是将超类型放在一个 table（支付）中，并为每个子类型（支付方式）创建单独的 table。超类型 table 和每个子类型 table.

之间存在 1:1 关系

示例，超类型 table:

Payment (PaymentID, PaymentMethodID, Date, UserID ...)

子类型：

CreditCardPayment(PaymentID, CardNumber, ....)

PayPalPayment(PaymentID, SecurityCode, ...)

WireTransfer(PaymentID, AccountNumber, ...)

当您创建付款时，您在付款中创建记录并在一笔交易中记录在其中一个子类型中。这种实现方式是一种很好的实现方式，因为它是规范化的，可以轻松扩展和防错。但不幸的是，它非常冗长，需要比非规范化解决方案更多的努力。

非规范化解决方案是创建一个付款 table 并为所有付款方式添加一堆列。当您创建新付款时，大多数列都是空的，只有应用程序逻辑知道应该定义哪些列。这个方案实现起来简单很多，但是问题比较明显。

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

付款表设计

Payment tables design

database

database-design

relational-database