我正在重新设计药房数据库系统并需要输入以查看新设计是否最佳或需要调整。
这是旧系统的快照..
可以看出,药房表存储药房信息及其地址和联系信息。药房被分组在一起用于开发票(药房组)或销售,广告其他用途(横幅组)。发票组可能具有不同的物理地址,不同的联系信息。
这是我的新设计。我已将药房和药房组表中的地址拆分为自己的表格,并为联系人创建了一个新表格。他们可以是技术联系人,帐户联系人,所有者联系人等,因此是contacttypes表。药房和药房可以有单独的联系信息,我想制作一个联系表,并有一个'linktype'和'linkid'列,以表明它是药房联系人还是药房团体联系人,但我不确定这是否是正确的方法。这是一个好的设计还是由于连接的数量而在数据检索方面成本很高?我注意到的另一件事是,在旧设计中,他们没有创建任何外键约束,尽管药房表具有pharmacy和bannergroupid对pharmacygroup和bannergroup的引用,可能节省数据检索的时间。这是一个好方法吗?
答案 0 :(得分:3)
你的设计对我来说很好看。在系统投入生产后,我总是倾向于在设计步骤上花费一些时间来重新组织数据。您永远不会事先知道管理/销售/财务人员会要求哪种报告,适当的关系设计会给您更多的自由。
此外,您不能仅因为性能问题而责怪几个额外的JOIN
。你应该总是看看:
在我看来,JOIN
将位于此列表的底部。
关于RI constraints(参照完整性),我已经看到了几个没有任何主键/外键运行的项目,以提高性能。主要的借口是:我们将所有检查嵌入到 Application 中, Application 是系统中任何更改的唯一来源。另一方面,他们同意,不知道系统是否处于一致状态(事实上,分析显示它们不是)。
我总是坚持在设计状态上创建所有可能的键/约束,因为总会有一些“牛仔”,他们会挖掘你的数据库并“调整”他们看起来更合适的数据。不过,您可能希望暂时禁用甚至删除批量数据操作的某些约束/索引,这也是official recommendation。
如果不确定,请创建2个测试数据库,一个包含,另一个没有约束。加载一些数据并比较查询性能。我认为它会是类似的。
在这里,我对你的草图的评论,决定都是你的。
contacts
相同的方式创建公共addresses
表格,即将contact_id
,owner_contact_id
等列添加到目标关系中引用来自contacts
table; contacttype
表中只有一列(如果您有一个共同的contacts
),最好将唯一一个字段移开并避开此表格; pharmacygroup
中,您的PK被命名为id
,而所有其他PK都遵循table
id模式,如果您在此处使用常用模式,则稍后编写脚本会更容易; addresses
表中,您有包含下划线的字段,例如street_name
,而在其他地方,您可以避免使用_
- 请考虑将其设为常用字词; 引用的命名方式不同。虽然它不是那么重要,但我确实有几个系统,我必须依赖约束的名称,所以最好在这里使用一些模式。我使用以下一个:
p_
,f_
,c_
,t_
,u_
或i_
用于主要,外键,检查约束,触发器,独特的和其他索引; 为什么我更喜欢以单数形式命名表?因为我总是使用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
);
它会部分复制您的初始groupcontacts
,但由两个FK和一个描述组成。
哪种方法更好我无法分辨,因为我不知道应用程序是如何设计的。
答案 1 :(得分:1)
你有2个联系表,我会创建一个,然后使用链接表链接groupcontacts和pharmacycontacts。我肯定希望将FK和PK关系设置为。