Sql db设计评论/建议_Sql_Database_Postgresql

Sql db设计评论/建议

sql database postgresql

Sql db设计评论/建议,sql,database,postgresql,Sql,Database,Postgresql,我正在重新设计一个药房数据库系统，需要输入，看看新的设计是最优的还是需要调整这是旧系统的快照可以看到，“药房”表存储药房信息以及地址和联系信息。药房分组用于开具发票（pharmacygroup）或销售、广告或其他目的（banner group）。发票组可能具有不同的物理地址、不同的联系信息这是我的新设计。我已将地址从pharmacy和pharmacygroup表拆分为自己的表，并为联系人创建了一个新表。他们可以是技术联系人、客户联系人、所有者联系人等，因此可以使用contacttypes

我正在重新设计一个药房数据库系统，需要输入，看看新的设计是最优的还是需要调整

这是旧系统的快照

可以看到，“药房”表存储药房信息以及地址和联系信息。药房分组用于开具发票（pharmacygroup）或销售、广告或其他目的（banner group）。发票组可能具有不同的物理地址、不同的联系信息

这是我的新设计。我已将地址从pharmacy和pharmacygroup表拆分为自己的表，并为联系人创建了一个新表。他们可以是技术联系人、客户联系人、所有者联系人等，因此可以使用contacttypes表。药房和药房组可以有单独的联系人信息，我曾想过创建一个联系人表，并有一个“linktype”和“linkid”列来指示是药房联系人还是药房组联系人，但我不确定这是否是一种正确的方法。这是一个好的设计，还是因为连接的数量，在数据检索方面会很昂贵？？我注意到的另一件事是，在旧的设计中，它们没有创建任何外键约束，尽管pharmacygroup和bannergroup的药房表有groupid和bannergroupid引用，可能是为了节省数据检索的时间。这是一个好方法吗

您有两个联系人表，我将创建一个，然后使用链接表链接groupcontacts和pharmacycontacts。我肯定想把FK和PK的关系设置为

我觉得你的设计不错。我总是更喜欢在设计步骤上有几个额外的连接，而不是在系统投入生产后花时间重新组织数据。你永远不会事先知道管理层/销售人员/财务人员会要求什么样的报告，适当的关系设计会给你更多的自由

此外，您不能将性能问题仅仅归咎于几个额外的

JOIN

s。您应该始终关注：

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

在我看来，

JOIN

s将位于此列表的底部

至于（引用完整性），我已经看到一些项目在运行时没有任何主键/外键来提高性能。主要的理由是：我们将所有检查嵌入到应用程序中，而应用程序是系统中任何更改的唯一来源。另一方面，他们同意，不知道系统是否处于一致状态（事实上，分析表明并非如此）

我始终坚持在设计状态上创建所有可能的关键点/约束，因为总会有一些“牛仔”在周围，他们会深入到您的数据库并“调整”数据，他们看起来更适合您。尽管如此，您可能希望临时禁用或甚至删除一些大容量数据操作的约束/索引，这也是一个问题

如果不确定，创建两个测试数据库，一个有约束，另一个没有约束。加载一些数据并比较查询性能。我想也会是这样

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

您可能希望创建一个通用的
```
联系人
```
表，方法与对
```
地址
```
所做的相同，即将
```
联系人id
```
、
```
所有者联系人id
```
等列添加到目标关系中，而不是引用
```
联系人
```
表中的关系
由于
```
contacttype
```
表中只有一列（如果您有一个常见的
```
contacts
```
），最好将唯一字段移开，避免使用此表
您的表似乎混合了单数/复数名称，最好在这里使用一种通用模式。我个人更喜欢单数
在
```
pharmacygroup
```
中，您的PK被命名为
```
id
```
，而其余的PK都遵循
```
table
```
id模式，如果您在此处使用公共模式，以后编写脚本会更容易
在代码>地址表中，有下划线的字段，如“代码> StrutEngEng/<代码>，而在其他地方，请避免<代码> <代码> -考虑使其通用；<李>
引用的名称不同。虽然这不是很重要，但我有几个系统必须依赖于约束的名称，所以最好在这里使用一些模式。我使用以下一种方法：
主键、外键、检查约束、触发器、唯一索引和其他索引的前缀
```
p
```
、
```
f
```
、
```
c
```
、
```
t
```
、
```
u
```
或
```
i
```
表的名称
引用的列约束/索引/触发器的名称

为什么我喜欢用单数形式命名表？因为我总是使用

表\u id模式来命名PK，而且IMHO药房id
看起来比药房id
更好。我使用这种方法是因为我有一堆通用脚本，在将数据加载到主表之前执行数据一致性检查时依赖于这种模式
编辑：
更多关于联系人的信息。
您可以在所有表中使用contact\u id
，使其成为主要联系人，无论这在您的应用程序中意味着什么。如果您需要更多的联系人来处理某些关系，那么您可以使用不同的前缀，如所有者联系人id
，销售联系人id
，等等
如果您希望在某些关系中有大量联系人，如pharmacygroup
，则可以添加如下额外表格：
CREATE TABLE pharmacygroupcontact (
    contactid     int4,
    groupid       int4,
    contact_desc  text
);

它部分复制您的初始groupcontacts，但包含两个FK和一个说明。
我不知道哪种方法更好，因为我不知道