Sql 哪种桌子设计更适合分为多个部分的天平？

我有一个数据库，需要将余额和国际收支分解成不同的“钱桶”，以显示它们是如何分配的。例如，有本金、利息、滞纳金、拒付支票费、杂项等。最多有10个不同的钱桶

这两种方法中哪一种是设计数据库的更好方法，为什么

方案A

PAYMENTS 
AccountId
// Other payment-related columns
TotalPaid 
PrincipalPaid
InterestPaid
MiscPaid
BadCheckChargesPaid
...

方案B

PAYMENTS
AccountId
// Other payment-related columns
TotalPaid

PAYMENT_DETAILS
PaymentId
PaymentTypeId
AmountPaid

---

在大多数情况下，只有1-3种不同的余额类型被使用

选项B是更好的规范化、更灵活的选项（以后很容易添加一个新的桶），并且会得到我的投票。

虽然规范化仙女经常会引诱你朝着后者的方向发展（就像我一样），但前者可能更明智。您只讨论了10列（不是500列），并且没有真正被打破的规范化规则。除非这个支付分配桶列表很有可能会增长，否则我会远离EAV结构，因为它会产生令人头痛的问题（以及一些查询中的无数连接）。

选项B对我来说似乎更好。关键在于您的应用程序是否设计为显示以下详细信息：

 Item             Amount
 --------------   ---------------
 Principal        $10.00
 Interest          $1.11

如果是这样，规范化版本不仅“更正确”，而且实际上以更接近应用程序要求的格式存储数据

---

对我来说，最大的问题是您是将付款总额存储在付款记录中，还是从明细中获取。

钱桶？听起来更像是“T”账户。。。最多，您需要两列：借方和贷方，以及一个表示利息/等的类型代码。您可以只使用一列，并使用负号表示借方或贷方（取决于分类科目）。我这里有一些空桶，您可以帮助我填充它们@瑞秋：这也会吸引我；EAV对我来说是邪恶的，因为我喜欢这种结构，尽管我知道它充满了惩罚和滥用的可能性。我不认为选项B是一种EAV方法。每个记录都是一个定义良好的项目，是付款的详细信息。不存在类型安全的问题，与按列方法相比，结构可能更接近用户对应用程序的需求（每个细节都有单独的行，底部有一个总和）。@Larry:EAV不必是松散类型的（尽管它经常是）。这遵循了EAV结构：实体（付款）、属性（付款类型）、价值（金额）。一开始似乎不是很多，但考虑到我们需要跟踪原始余额、应计余额、已支付余额和当前余额，付款应跟踪费用（我们保留的付款百分比）和实际付款之外的剩余余额，它突然从每个表中的10列变为Accounts表中的40列和Payment表中的30列table@Rachel：如果你说的是40，那么我会转到第二个表结构。在大多数情况下，用户只关心总付款金额。如果他们对详细信息感兴趣，他们可以点击一个付款条目，查看如何在此处显示的表单中进行细分的详细信息。+1因为它不仅是标准化的，而且标准化选项允许每个bucket有多个条目，所有条目都被单独跟踪。在金融应用程序中，这几乎是一项绝对要求。