用于跟踪和共享费用的数据库设计

Question

我想设计一个网络应用程序来跟踪一个组织成员的财务情况。某些函数非常类似于斯普利特。我使用MWE数据库图定义了我的需求：

• “财务”表:每个用户将有一个个人财务帐户，我使用以下三个红色表：

​

• "SharedExpense“表:每个用户都可以与许多‘共享费用组’的其他用户共享费用。对于每个组，我使用以下三个蓝色表：

​

(请注意每个用户如何定义其份额的数量，以及共享费用的类别。UserShare表使用复合主键。)

The problem：我必须将用户关联到他们的3个个人“财务”表和3N "SharedExpense“表( N是用户所属的‘共享费用-组’的数量)。

尝试解决方案

1. 多个数据库。每个用户都有自己的“财务”表的唯一数据库。每个“共享费用组”在服务器上都有一个唯一的数据库。然后，我可以将一个主数据库中的用户与以下四个紫色表关联起来：

缺点:外键来自不同的数据库，大量的数据库需要备份。

1. 多张桌子。我可以在同一个数据库中创建所有表，并将它们与四个绿色主表关联起来：

在这里，表的数量是一个潜在的问题。如果有M用户和N的共享费用组，那么就会有3M + 3N表！

的问题是：是否有更优雅、更简单的数据库设计？如果没有，上述两种解决方案中哪一种更好，为什么？

链接到相关的，以前的StackOverflow问答

• 个人理财应用数据库设计
• 用于随时间跟踪进度的数据库设计
• 用于家用票据分割数据库的SQL
• 将1个数据库与多个表与多个数据库进行比较，每个数据库中的表较少

Answer 1

在一个总结中有很多要描述的挑战，但我会挑出几个。

1. 基本的设计冲突:例如为每个用户创建一个表/数据库
2. 实体设计，3NF:如category.budget和ledger.transaction_type
3. 参考完整性/关系设计：
   • 帐户是一个用户的帐户，但是帐户表不包含用户id；
   • 用户共享是分类账的一个子集，但它们都指向用户；

​

1. 对象命名关注点：
   • 明确一致的命名实体，基于实际使用。成员是用户还是用户是成员？如果它们是相同的，请选择一个名称。如果它们不一样，设计就不一样了。员工是否使用客户或客户而不是会员？
   • 密钥命名的一致性。密钥名应该将其直接绑定到源实体。Members.ID应该被引用为members_id，而不是user_id。但是，在更正之前，请参阅下一个条目。
   • 在实体数中保持一致。普遍的共识是，名称应该描述单个记录(用户)，而不是所有记录(用户)。
   • ledger.spent_on --这个名字显然不是约会。它也可以指向用户或类别。属性名称应该描述属性，而不需要额外的解释。例如，ledger.Purchase_Date是不言自明的。它还应清楚地说明它与实体的关系。UserShare.Share并没有真正告诉我它包含了什么。

​

很抱歉直言不讳，但我会重新开始。将您拥有的作为一个良好的试运行，然后使用您所拥有的其他信息重新开始。

• 问你的设计问题(所有用户都是会员吗？)所有成员都是用户吗？)。如果答案不是“是”或“否”，那就进一步细分。
• 尝试什么-如果方案(如果共享分类账超过类别预算怎么办？如果类别预算发生变化，将如何看待以前的支出？)
• 考虑哪些报告问题可能会被问到(谁超出了预算？我们在这个类别上要花多少钱？)然后考虑这个查询来回答这个问题。

阅读3NF，也许还有一些更高的标准化水平。虽然3NF几乎是最小的规范化，但更高级别变得越来越专业化，并且可能适合或不适合您的设计。

你越了解你的数据和业务，你的设计就会越好，你的最终产品也会越好。