设计数据库模式的问题答案

【问题标题】：Problems with designing of the database schema设计数据库模式的问题
【发布时间】：2017-03-18 06:43:02
【问题描述】：

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

我为我的项目设计了一个数据库架构。

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

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

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

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

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

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

更新

如果我要为表“生产者”和“消费者”分配角色，那么我必须为它们赋予表征实体“用户”和“组织”的属性。一方面，如果角色的数量增加，那么属性的数量就会增加。该路径导致表属性的拥塞。并且不同角色的某些属性将符合 NULL 值。另一方面，一个角色的一个属性可以符合另一个角色的多个属性。例如，实体“组织”的属性“名称”符合实体“用户”的属性“名字”、“中间名”、“姓氏”和“用户名”。第三，我仍然想将模型“生产者”、“组织”、“用户”和“消费者”彼此分开。

【问题讨论】：

我认为你正在努力解决的是“角色”的话题。这是一个非常普遍的问题。一个人可以扮演很多角色。这并不使一个人成为一种角色，因为这意味着它必须始终如此。你可能会发现建立角色扮演关系可以解决问题，但我没有时间仔细分析你的问题。您可能还会发现 qua 实体（例如，作为生产者的人）有助于维护历史和其他事实。
确实很棘手。吉姆说的是对的。我可能会在晚上晚些时候调查一下（除非吉姆提供了一个好的答案）。
我认为你一次问了太多问题，实际上。我数了四个显性问题和几个隐性问题。一切都源于问题域中存在的不准确模型。我建议你解决这个问题。然后，UML 和 ER 都可以轻松地与之对齐。事实上，一个 UML 模型可以为您的 OOP 和 DB 提供基础。
完全同意吉姆的观点。 “未来，我在计划……”是一个全新的故事。您可能会将此作为单独的问题提出，但可能会因为过于宽泛而被关闭。试一试。我现在将考虑您的 First 和 Second （我认为后者也是另一个故事；所以希望 First 得到答案）。
您的更新对我来说毫无意义。这不是关于如何进行分析和设计的来回课程的论坛。请提出一个新的、直接的问题，不需要书的章节来回答。

标签： database-design uml database-schema entity-relationship er-diagrams

【解决方案1】：

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

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

这肯定会提供很多调整和性能选项。但您可能还会有一些实现开销。

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

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

【讨论】：