我们正在构建的软件有“客户”。客户可以是个人或组织。

我真的很想为此创建一个最佳模式。

我有这些考虑。

1. 一个人可以有一个或多个联系人（例如电话、电子邮件）
2. 一个人可以有一个或多个地址
3. 一个组织可以有一个或多个联系人（例如电话、电子邮件）
4. 一个组织可以有一个或多个地址
5. 一个组织可以有一个或多个与之相关的人员。

我希望应用程序能够适当地扩展，因此架构应该适合此选择。

我正在尝试实现以下目标。

SELECT * FROM Customers + a few joins.

1. Person | NULL | John Doe | Primary Organisation Contact | Primary Address

2. Organisation | Acme Ltd | Jane Doe | Primary Organisation Contact | Primary Address

我应该如何创建一个最佳模式来关联上述内容？

我附上了一个粗略的 Visual Schema 层次结构 - 我知道我离得很远！！我确定我犯了错误。

是否有可能根据是个人还是组织来获得一组已婚结果？

将个人和联系人/地址加入客户很简单，但您如何加入组织的主要联系人/地址？

有没有更简单的方法来实现我的蜘蛛图外观架构。？？

我正在处理的应用程序的核心功能似乎只是关联实体。因此，一对多关系会产生“元数据”，这些“元数据”只会为我们的应用程序功能提供（以一种或另一种方式）关联实体。

现在我们有一个实体关系图 (ERD)，它有很多一对多（超过 10 个表）和只有一个关联实体。它对该模型或应用程序有何看法？

是否可以改进，即，如果改进 ERD 以添加更多关联实体，应用程序是否可以绕过更多功能？

关联实体很少是否意味着应用程序的功能不会很丰富？

其他注意事项

我想知道的是：如果项目范围说明书导致 ERD 只有一个多对多关系和十几个一对多关系，那么这是否意味着该项目没有解决很多问题（功能）除了只数字化大量数据？

我认为，如果多对多较少，它们一开始只会镜像（除非我们为其他目的创建连接查询......）。

或者简单地说：大量的多对多关联是否意味着软件的功能将比少对多的软件更丰富（不要在这个想法中包括连接查询）？

我正在做一个个人项目，我想在其中创建一个数据库，其中包含每个上市公司的每个所有者的信息。例如，说“Sears INC”，程序将获取“Sears INC”中每个所有者的信息。这就是想法。但是我很难构建这个数据库。我对这个主题只有有限的经验和知识，所以任何指导将不胜感激。

现在我首先考虑制作一个名为公司的表格，并为它们提供所有唯一的 ID，并为每个公司制作一张表格。然后在这些表中将是所有所有者及其唯一 ID。这将链接到他们的信息。我试图在这里形象化：

现在我知道为每个公司创建一个表会很乏味，但我想不出任何其他方法来做到这一点。众所周知，每个公司可能有相同的所有者，因此使用 Owner_ID 来识别每个所有者是有意义的。

我在一个 CVS 文件中有所有其他数据，在我构建了数据库之后，我可以很容易地将这些数据导入到 PostgreSQL 中。

任何帮助将不胜感激。

TL：博士；创建一个可按公司名称搜索的股票所有者数据库，并且需要帮助来构建数据库以实现最大效率。

一个人只能有一个电话和一个地址。公司也是如此，因为我制作了一个脚本，可以根据这些信息查找电话。我区分知道一个实体是公司还是个人的方法是使用名为 F_Org 的列，该列对于公司来说将大于 4 位数字。这一切都由脚本处理。