开发人员和数据库设计师，嗨！
我为我的项目设计了一个数据库模式。
该项目涉及“生产者”和“消费者”之间的关系。但是，如果“生产者”可能既是“用户”又是“组织”，那么“消费者”可能只是“用户”（尽管只是现在）。如果考虑我项目的对象模型，它主要由两个基本接口组成——“生产者”和“消费者”。关系将在“组织”和“用户”主要类的实例之间，更重要的是，“组织”类实现了“生产者”接口，“用户”类实现了“生产者”和“Сonsumer”的接口。例如，在使用我的应用程序的一段时间内，一些用户必须能够向其他用户出售商品，并且能够从任何人那里购买商品。
将来，我计划将最需要的支付系统集成到项目中。如果您有使用支付系统的经验，请告诉我，它将如何改变模型和数据库架构。我需要添加“法人实体”和“个人”的实体吗？
我根据上面的描述设计了 ER 图，但它有几个缺点。
首先，ER-description 和UML description 之间没有完全的对应关系。我需要为接口分配分离表吗？我不知道。实际上，在这种情况下，根据 ER 描述，可以说“生产者”和“消费者”是“组织”和“用户”的超类。但实际上它们只是接口。
其次，我需要最简单的设计来提供足够灵活的存储访问，而不需要不必要的“JOIN”。也许我应该完全放弃接口实现？但我完全赞成使用 OOP 财富。是否可以在数据库级别使用接口实现？我知道可以使用继承。但我不知道这些技巧将如何影响生产力——因为以前的所有项目都不需要使用超类和接口。我将使用 PostgreSQL 作为关系 DBMS。
请分享您成功的数据库方案的经验和实现。
更新
如果我要为表“生产者”和“消费者”分配角色，那么我必须为它们赋予表征实体“用户”和“组织”的属性。一方面，如果角色的数量增加，那么属性的数量就会增加。该路径导致表属性的拥塞。并且不同角色的某些属性将符合 NULL 值。另一方面，一个角色的一个属性可以符合另一个角色的多个属性。例如，实体“组织”的属性“名称”符合实体“用户”的属性“名字”、“中间名”、“姓氏”和“用户名”。第三，我仍然想将模型“生产者”、“组织”、“用户”和“消费者”分开
