设计数据库模式的问题

Question

开发人员和数据库设计师，嗨！

我为我的项目设计了一个数据库模式。

该项目涉及“生产者”和“消费者”之间的关系。但如果'制作人'可能既是'用户'又是'组织'，那么'消费者'可能只是'用户'（虽然它只是现在）。如果要考虑我的项目的对象模型，它主要包括两个基本接口 - “生产者”和“消费者”。关系将在主要类的实例之间进行，即'组织'和'用户'，更多'组织'类实现'生产者'接口，'用户'类实现'生产者'和'Сonsumer'的接口。例如，在使用我的应用程序的一段时间内，某些用户必须能够向其他用户销售商品，并且能够从任何人那里购买商品。

将来，我计划将最需要的支付系统整合到项目中。如果您有使用支付系统的经验，请告诉我，它将如何改变模型和数据库架构。我是否需要添加“法律实体”和“个人”的实体？

我根据上面的描述设计了ER图，但它有几个缺点。

首先，ER-description和UML描述之间没有完全对应。我是否需要为接口分配分离表？我不知道。实际上，在这种情况下，根据ER描述，可以说“生产者”和“消费者”是“组织”和“用户”的超类。但实际上它们只是接口。

其次，我需要最简单的设计，使存储的访问足够灵活，没有不必要的'JOIN'。也许我应该完全放弃接口实现？但我全都是为了使用OOP财富。是否可以在数据库级别使用接口实现？我知道可以使用继承。但我不知道这些技巧会如何影响生产力 - 因为之前的所有项目都不需要使用超类和接口。我将使用PostgreSQL作为关系DBMS。

请分享您的成功数据库方案的经验和实施。

更新

如果我将为表'Producer'和'Consumer'分配角色，那么我将必须给它们表征实体'User'和'Organization'的属性。一方面，如果角色数量增加，则属性数量增加。此路径需要表的属性拥塞。并且不同角色的某些属性将符合NULL值。另一方面，一个角色的一个属性可以符合另一个角色的多个属性。例如，实体“组织”的属性“名称”符合实体“用户”的属性“名字”，“中间名”，“姓氏”和“用户名”。第三，我仍然希望将模型“制作人”，“组织”，“用户”和“消费者”彼此分开。

Answer 1

可能有很多方法，没有一种方法是最佳的。因此，作为架构师，您需要权衡架构的不同优缺点。我可能会从构建数据库抽象开始。这取决于您需要多少持久性对象。也就是说，我是否需要即时持久性，或者它是否足以让一些阴影可以在后台运行。

所以基本上你有表依赖于相应的类。你可以简单地让它打开如何实现这种依赖。某些编程语言提供了将一个映射到另一个的脚手架。这很方便，可以节省大量的打字/设计。当然它不是很灵活。因此，基于此，您应该考虑各种选项。是否有必要在类中实现数据库访问并让它们实现一些串行器接口？

这肯定会提供很多调整和性能选择。但是你可能也会有一些实现开销。

或者更好的是有一些影子机制，你可以订阅同时保存你的状态？

因此，为了做出正确的设计决策，您需要考虑对象和数据库如何相互关联以及此绑定需要多强。不幸的是，没有银弹。