用于跟踪和共享费用的数据库设计
提问于 2018-11-29 05:37:19
我想设计一个网络应用程序来跟踪一个组织成员的财务情况。某些函数非常类似于斯普利特。我使用MWE数据库图定义了我的需求：
- “财务”表:每个用户将有一个个人财务帐户，我使用以下三个红色表：
- "SharedExpense“表:每个用户都可以与许多‘共享费用组’的其他用户共享费用。对于每个组，我使用以下三个蓝色表：
(请注意每个用户如何定义其份额的数量，以及共享费用的类别。UserShare表使用复合主键。)
The problem：我必须将用户关联到他们的3个个人“财务”表和3N "SharedExpense“表( N是用户所属的‘共享费用-组’的数量)。
尝试解决方案
- 多个数据库。每个用户都有自己的“财务”表的唯一数据库。每个“共享费用组”在服务器上都有一个唯一的数据库。然后，我可以将一个主数据库中的用户与以下四个紫色表关联起来：
缺点:外键来自不同的数据库，大量的数据库需要备份。
- 多张桌子。我可以在同一个数据库中创建所有表，并将它们与四个绿色主表关联起来：
在这里，表的数量是一个潜在的问题。如果有M用户和N的共享费用组，那么就会有3M + 3N表！
的问题是：是否有更优雅、更简单的数据库设计？如果没有，上述两种解决方案中哪一种更好，为什么？
链接到相关的，以前的StackOverflow问答
回答 1
Stack Overflow用户
发布于 2018-11-29 10:27:02
在一个总结中有很多要描述的挑战，但我会挑出几个。
- 基本的设计冲突:例如为每个用户创建一个表/数据库
- 实体设计，3NF:如category.budget和ledger.transaction_type
- 参考完整性/关系设计：
- 帐户是一个用户的帐户，但是帐户表不包含用户id；
- 用户共享是分类账的一个子集，但它们都指向用户；
- 对象命名关注点：
- 明确一致的命名实体，基于实际使用。成员是用户还是用户是成员？如果它们是相同的，请选择一个名称。如果它们不一样，设计就不一样了。员工是否使用客户或客户而不是会员？
- 密钥命名的一致性。密钥名应该将其直接绑定到源实体。Members.ID应该被引用为members_id，而不是user_id。但是，在更正之前，请参阅下一个条目。
- 在实体数中保持一致。普遍的共识是，名称应该描述单个记录(用户)，而不是所有记录(用户)。
- ledger.spent_on --这个名字显然不是约会。它也可以指向用户或类别。属性名称应该描述属性，而不需要额外的解释。例如，ledger.Purchase_Date是不言自明的。它还应清楚地说明它与实体的关系。UserShare.Share并没有真正告诉我它包含了什么。
很抱歉直言不讳，但我会重新开始。将您拥有的作为一个良好的试运行，然后使用您所拥有的其他信息重新开始。
- 问你的设计问题(所有用户都是会员吗？)所有成员都是用户吗？)。如果答案不是“是”或“否”，那就进一步细分。
- 尝试什么-如果方案(如果共享分类账超过类别预算怎么办？如果类别预算发生变化，将如何看待以前的支出？)
- 考虑哪些报告问题可能会被问到(谁超出了预算？我们在这个类别上要花多少钱？)然后考虑这个查询来回答这个问题。
阅读3NF，也许还有一些更高的标准化水平。虽然3NF几乎是最小的规范化，但更高级别变得越来越专业化，并且可能适合或不适合您的设计。
你越了解你的数据和业务，你的设计就会越好，你的最终产品也会越好。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/53540329
复制
腾讯云开发者
