db设计评论/建议

我正在重新设计一个药房数据库系统，并需要输入信息来查看新设计是否最优或需要调整。db设计评论/建议

这里是旧系统的快照..

Pharmacy Db Old

可以看出，药店表店药房信息，其地址和联系信息。为了开具帐单（药房组），药店被分组在一起，或者用于销售，宣传其他目的（横幅集团）。发票组可能有不同的物理地址，不同的联系信息。

这是我的新设计。我已将药房和药房组表格中的地址分成了自己的表格，并为联系人制作了一张新表格。他们可能是技术联系人，帐户联系人，所有者联系人等，因此是联系人表格。药房和药房组可以有单独的联系信息，我想制作一个联系表，并有一个“linktype”和“linkid”栏来表明它是否与药房联系人或药房组联系，但我不确定这是否是一个正确的方法。这是一个好的设计，还是会因数据检索而导致代价高昂？我注意到的另一件事是，在旧设计中，他们没有创建任何外键约束，尽管药房表对药房组和横幅组都有groupid和bannergroupid引用，可能为节省数据检索时间。这是一个好方法吗？

Pharmacy Db Design New

来源

2012-04-11 Angela

您的列宽可能太窄。意见建议：姓氏= 35，名字= 35，电子邮件= 255 – onedaywhen 2012-04-11 07:27:52

您的设计看起来不错。系统投入生产后，我总是喜欢在设计阶段多花点时间重新组织数据。您事先不知道管理/销售/财务人员会要求什么样的报告，适当的关系设计会给您更多的自由。

此外，您的性能问题不能只归咎于几个额外的JOIN。你应该总是看：

数据卷（和物理数据布局），
交易量和密度，
I/O，CPU，内存使用情况，
您的RDBMS的配置，
SQL查询质量。

在我看来，JOIN s将在此列表的底部。

至于RI constraints（参照完整性），我见过一些没有任何主键/外键的项目以提高性能。主要借口是：我们已将所有检查嵌入应用程序和应用程序是系统中任何更改的唯一来源。另一方面，他们同意，不知道系统是否处于一致状态（事实上，分析表明他们不是）。

我总是坚持在设计状态上创建所有可能的键/约束，因为总会有一些“牛仔”在身边，他们会挖掘数据库并“调整”他们看起来更合适的数据。但是，您可能需要暂时禁用或删除批量数据操作的一些约束/索引，这也是official recommendation。

如果不确定，请创建2个测试数据库，其中一个测试数据库与另一个没有限制。加载一些数据并比较查询性能。我认为它会相似。

在这里，我对你的草图的评论，决定都是你的。

您可能希望创建一个普通的contacts表你为addresses的方式相同，即添加contact_id，owner_contact_id等列到目标的关系，而不是引用来自contacts表的关系;
由于您在contacttype表中只有一列（如果您有共同的contacts），最好将唯一的字段移开并避开此表;
你似乎有混合的单/复数名称为您的表，更好地坚持一个共同的模式在这里。我个人比较喜欢单数;
pharmacygroup您的PK名为id，而其余所有PK都遵循table id模式，如果您在此处使用通用模式，稍后编写脚本将更容易;
在addresses表中，您有带下划线的字段，如street_name，而在其他地方您可以避免使用_ - 考虑使其相同;
参考文献的命名有所不同。尽管它并不那么重要，但我确实有一些系统必须依赖约束条件的名称，所以最好在这里使用一些模式。我用下面的一个：
1. 前缀p_，f_，c_，t_，u_或i_小学，外键，检查约束，触发器，独特等指标;
2. 表名;
3. 列约束名称/索引/触发器是指。

为什么我喜欢在命名单数形式表？因为我总是使用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和一个描述。哪种方法更好我不知道，因为我不知道如何设计应用程序。

来源

2012-04-11 05:49:27 vyegorov

thnks的详细答案..我一定会研究所有的建议特别是。关于命名约定，但是现在，我对设计部分更感兴趣。对于常见联系人表，您是否建议我为药房和药房组表添加不同类型的contact_id？因此，对于类型所有者，将有owner_contact_id，对于类型帐户，它将是account_contact_id等。如果将新类型引入行中，这将如何考虑？ – Angela 2012-04-11 11:01:37

你有2个联系表，我想创建一个，然后使用链接表链接groupcontacts和pharmacycontacts。我肯定希望将FK和PK关系设置为。

来源

2012-04-11 04:29:05 TheRealTy

嗨，我也在考虑一张桌子，我不确定链接表，你能详细说明一点吗？ – Angela 2012-04-11 10:56:46

db设计评论/建议

回答

相关问题