mysql - 用于跟踪和分摊费用的数据库设计

Question

我想设计一个网络应用程序来跟踪组织成员的财务状况。某些功能与 Splittr 非常相似.我使用 MWE 数据库图表定义我的要求:

• “财务”表:每个用户都有一个个人财务帐户，为此我使用了以下三个红色表:
• “SharedExpense”表:每个用户都可以与许多“共享费用组”中的其他用户共享费用。对于每个组，我使用以下三个blue 表:

(请注意每个用户如何定义他们的共享金额，以及自己的共享费用类别。UserShare 表使用复合主键。)

问题:我必须将用户与他们的 3 个个人“财务”表和 3N“SharedExpense”表相关联(其中 N 是用户所属的“共享费用组”的数量)。

尝试的解决方案:

1. 多个数据库。每个用户的“财务”表都有一个唯一的数据库。每个“共享费用组”在服务器上都有一个唯一的数据库。然后，我可以将一个主数据库中的用户与以下四个 purple 表相关联:
   
   缺点:外键来自不同的数据库，需要备份大量的数据库。

2. 多个表。我可以在同一数据库中创建所有表，并将所有表与四个 green 主表相关联:
   在这里，表的数量是一个潜在的问题。如果有 M 用户和 N 'shared-expense-groups，那么就会有 3M + 3N 表!

   <

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

相关的、以前的 StackOverflow 问答链接:

• Personal finance app database design
• Database design for tracking progress over time
• SQL for a Household Bill splitting db
• Comparing 1 Database with Many Tables to Multiple Databases with Fewer Tables in Each

Answer 1

要在摘要中描述所有的挑战太多了，但我会挑出一些。

1. 基本设计违规:例如每个用户一个表/数据库
2. 实体设计，3NF:如category.budget 和 ledger.transaction_type
3. 参照完整性/关系设计:
   • 帐户是一个用户，但帐户表不包含用户标识；
   • usershare 是 ledger 的一个子集，但它们都指向一个用户；
4. 对象命名问题:
   • 基于实际使用情况的清晰一致的命名实体。成员(member)是用户还是用户是成员(member)？如果它们相同，请选择一个名称。如果它们不相同，则设计不同。员工是否使用客户或顾客而不是成员(member)？
   • key 命名的一致性。键名应直接将其与源实体联系起来。 Members.ID 应引用为 members_id，而不是 user_id。但是，请在更正此之前查看下一个条目。
   • 在您的实体多元化方面保持一致。普遍的共识是名称应该描述单个记录(用户)而不是所有记录(用户)。
   • ledger.spent_on - 这个名字显然不是一个日期。它也可以指向用户或类别。属性名称应该描述属性而不需要额外的解释。例如，ledger.Purchase_Date 是不言自明的。还应该清楚它与实体的关系。 UserShare.Share 并没有真正告诉我它包含什么。

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

• 就您的设计提出问题(所有用户都是成员(member)吗？所有成员(member)都是用户吗？)。如果答案不是"is"或“否”，请进一步分割。
• 尝试假设情景(如果共享分类帐超出类别预算怎么办？如果类别预算发生变化，将如何看待之前的支出？)
• 考虑可能会问哪些报告问题(谁超出了预算？我们在这个类别上花了多少钱？)，然后考虑回答问题的查询。

阅读 3NF 以及一些更高的规范化级别。尽管 3NF 几乎是最低规范化，但更高级别变得越来越特化，可能适合也可能不适合您的设计。

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