你的设计对我来说很好。我总是更喜欢在设计步骤中有几个额外的连接,而不是在系统投入生产后花时间重新组织数据。你永远不知道管理层/销售/财务人员会要求什么样的报告,适当的关系设计会给你更多的自由。
此外,您不能只JOIN
将性能问题归咎于几个额外的 s。您应该始终查看:
- 数据量(和物理数据布局),
- 交易金额和密度,
- I/O、CPU、内存使用率、
- 您的 RDBMS 配置,
- SQL 查询质量。
在我看来,JOIN
s 将在这个列表的底部。
至于RI 约束(参照完整性),我已经看到几个项目在没有任何主键/外键的情况下运行以提高性能。主要借口是:我们将所有检查嵌入到应用程序中,而应用程序是系统中任何更改的唯一来源。另一方面,他们同意,目前尚不清楚系统是否处于一致状态(事实上,分析表明并非如此)。
我总是坚持在设计状态上创建所有可能的键/约束,因为总会有一些“牛仔”,他们会挖掘你的数据库并“调整”他们看起来更合适的数据。不过,您可能希望暂时禁用甚至删除一些用于批量数据操作的约束/索引,这也是官方建议。
如果不确定,创建 2 个测试数据库,一个有约束,另一个没有约束。加载一些数据并比较查询性能。我认为这将是相似的。
在这里,我对你的草图的评论,决定都是你的。
为什么我更喜欢以单数形式命名表?table
因为我总是使用_id 模式命名 PK ,而恕我直言pharmacy_id
看起来更好pharmacies_id
。我使用这种方法是因为我有一堆通用脚本,它们在将数据加载到主表之前执行数据一致性检查时依赖于这种模式。
编辑:
有关联系人的更多信息。您可以contact_id
在所有表格中使用,使其成为主要联系人,无论这在您的应用程序中意味着什么。如果您需要更多联系人来处理某些关系,那么您可以使用不同的前缀,例如owner_contact_id
,sales_contact_id
等。
如果您希望有大量联系人用于某些关系,例如pharmacygroup
,那么您可以添加一个额外的表格,如下所示:
CREATE TABLE pharmacygroupcontact (
contactid int4,
groupid int4,
contact_desc text
);
它部分复制了您的 initial groupcontacts
,但包含两个 FK 和一个描述。我不知道哪种方法更好,因为我不知道应用程序是如何设计的。