我想设计一个web应用程序来跟踪组织成员的财务状况。某些函数与splittr非常相似。我使用mwe数据库图定义我的需求：
“财务”表：每个用户将有一个个人财务帐户，我使用以下三个红色表：
“sharedexpense”表：每个用户可以在许多“共享开支组”中与其他用户共享开支。对于每组，我使用以下三个蓝色表格：
（请注意，每个用户如何定义其分摊的金额以及分摊费用的类别。usershare表使用复合主键。）
问题是：我必须将用户与他们的3个个人“财务”表和 3N “sharedexpense”表（其中 N 是用户所属的“共享开支组”的数目）。
尝试的解决方案：
多个数据库。每个用户的“财务”表都有一个唯一的数据库。每个“共享开支组”在服务器上都有一个唯一的数据库。然后，我可以将一个主数据库中的用户与以下四个紫色表关联起来：
缺点：外键来自不同的数据库，需要备份大量的数据库。
多个表。我可以在同一个数据库中创建所有表，并将它们与四个绿色主表相关联：
在这里，表的数量是一个潜在的问题。如果有的话 M 用户和 N '共享开支组，则 3M + 3N table！
问题是：有没有更优雅、更简单的数据库设计？如果不是，以上两种解决方案中哪一种更好？为什么？
链接到相关的，以前的stackoverflow问答：
个人理财app数据库设计
跟踪进度的数据库设计
家庭账单拆分数据库的sql
比较具有多个表的一个数据库与每个数据库中具有较少表的多个数据库
1条答案
按热度按时间tnkciper1#
在总结中有很多东西可以描述所有的挑战，但我会挑选一些。
基本设计冲突：例如每个用户的表/数据库
实体设计，3nf：如类别.预算.分类帐.交易类型
参照完整性/关系设计：
帐户为一个用户，但帐户表不包含用户id；
usershare是ledger的一个子集，但它们都指向一个用户；
对象命名问题：
根据实际使用情况，命名实体清晰一致。会员是用户还是用户是会员？如果它们相同，请选择一个名称。如果它们不一样，设计就不同了。员工使用客户还是客户而不是会员？
密钥命名的一致性。键名应该直接将其绑定到源实体。members.id应被引用为members\u id，而不是user\u id。但是，在更正此错误之前，请参阅下一项。
在你的实体中保持一致。一般的共识是名称应该描述单个记录（用户），而不是所有记录（用户）。
ledger.used d on-这个名字显然不是日期。它也可以指向用户或类别。属性名应该描述属性，而不需要额外的解释。例如，ledger.purchase\u date是不言自明的。还应明确其与实体的关系。usershare.share并没有告诉我它包含什么。
抱歉直说，我要重新开始。把你所拥有的当作一个好的试运行，然后使用你所拥有的额外信息重新开始。
询问您的设计问题（所有用户都是成员吗？所有成员都是用户吗？）。如果答案不是“是”或“否”，请进一步细分。
尝试假设情景（如果共享分类帐超出类别预算怎么办？如果类别预算发生变化，如何看待以前的支出？）
考虑可能会问哪些报告问题（谁超出了预算？我们在这个类别上花费了多少？），然后考虑这个查询来回答这个问题。
阅读3nf，也许还有一些更高的标准化级别。尽管3nf几乎是最小的标准化，但更高的级别变得越来越专业化，可能适合也可能不适合您的设计。
你越了解你的数据和业务，你的设计就越好，你的最终产品也就越好。