您的设计对我来说很好。我总是更喜欢在设计步骤中加入一些额外的连接，而不是花时间在系统投入生产后重新组织数据。您永远不会事先知道管理层/销售人员/财务人员会要求什么样的报告，而适当的关系设计将为您提供更多的自由。
同样，您不能仅将几个额外的
JOINs归咎于您的性能问题。您应该始终注意：
- 数据量（和物理数据布局），
- 交易金额和密度，
- I / O，CPU，内存使用率，
- 您的RDBMS配置，
- SQL查询质量。
我认为
JOINs将在此列表的底部。
关于RI约束（参照完整性），我已经看到了几个没有任何主键/外键来运行以提高性能的项目。主要借口是：我们将所有检查都嵌入到
应用程序中， 而 应用程序 是系统中任何更改的唯一来源。另一方面，他们同意，尚不清楚系统是否处于一致状态（实际上，分析表明它们不是）。
我始终坚持在设计状态上创建所有可能的键/约束，因为周围总是会有一些
流氓''，他们会挖掘您的数据库并调整’‘看起来更合适的数据。不过，您可能想暂时禁用甚至放弃一些用于批量数据操作的约束/索引，这也是官方建议。
如果不确定，则创建2个测试数据库，一个有约束，另一个无约束。加载一些数据并比较查询性能。我认为这将是相似的。
在这里，我对您的草图的评论，决定全由您决定。
- 您可能希望创建一个普通的
contacts
表你做了同样的方式addresses
，即加contact_id
，owner_contact_id
等列到目标的关系，而不是引用来自关系contacts
表; - 由于
contacttype
表中只有一列（以防万一contacts
），因此最好将唯一的字段移开并避免使用此表。 - 您的表似乎混合使用单/复数名称，最好在此处坚持使用通用模式。我个人更喜欢单数。
- 在
pharmacygroup
您的PK中命名为id
，而所有其他PK都遵循table
id模式，如果以后在此处使用通用模式，则以后编写脚本会更容易。 - 在
addresses
表中，您有带下划线的字段，例如street_name
，而在其他地方则避免_
使用…考虑使其通用; 引用的名称不同。尽管不是很重要，但我确实有几个系统必须依靠约束的名称，因此最好在这里使用一些模式。我使用以下之一：
- 前缀
p_
，f_
，c_
，t_
，u_
或i_
小学，外键，检查约束，触发器，独特等指标; - 表名；
- 列约束/索引/触发器所引用的名称。
- 前缀
为什么我更喜欢用单数形式命名表？因为我总是使用
table_id模式命名PK
，所以IMHO
pharmacy_id看起来更好
pharmacies_id。我使用这种方法是因为我有一堆通用脚本，这些脚本在将数据加载到主表之前执行数据一致性检查时都依赖于此模式。
编辑： 更多关于联系人。您可以
contact_id在所有表中使用它，使其成为 主要联系人
，无论这对您的应用程序可能意味着什么。如果您需要更多的接触是有一些关系，那么你可以用不同的前缀，比如去
owner_contact_id，
sales_contact_id等等。
如果您希望为某种关系而存在大量联系人，例如
pharmacygroup，则可以添加一个额外的表，如下所示：
CREATE TABLE pharmacygroupcontact ( contactid int4, groupid int4, contact_desc text);
它部分复制了您
groupcontacts的姓名缩写，但由两个FK和一个说明组成。我不知道哪种方法更好，因为我不知道应用程序是如何设计的。
