postgresql - 数据库设计决策 : normalization or repetition?

标签 postgresql optimization database-design

我正在构建一个交付系统,到目前为止,我的设计看起来像这样:

erd

问题是,我经常需要一个看起来像这样(非常分层)的结构(数组、json、对象...):

hierarchy

这样做的问题是,它会产生大量重复的 StreetAddress、DeliveryPoint 和 Customer,因为每个 Itinerary 都会创建很多这样的信息,而且行程看起来与其他的非常相似。 好的部分是,只需几个连接,一切都会很漂亮。

使用第一个模式,创建第二个结构会很奇怪,但它是可能的。

关于如何控制重复并仍然为上述结构获得易于查询的模式有什么想法吗?

我正在使用:

  • PostgreSQL 9.1
  • PHP 5.5
  • Symfony 框架标准版 2.4.0-BETA1(含 Doctrine)

[如果有人想知道我是如何绘制模式的:www.gliffy.com]

最佳答案

重复和规范化并不总是对立的问题。

这是基本问题:

规范化本身不关心重复,而是关心函数依赖

重复是错误的问题。功能依赖是正确的问题。在您的某些情况下,地址非常难以确定函数相关性,因为那里有太多约定,即使您这样做了,您仍然会遇到格式问题。

深入了解的一个简单方法是询问给定数据可能发生变化的原因。良好的规范化设计限制了给定数据可能需要更改的原因。现在,考虑到这一点,您似乎需要为客户存储历史位置,在我看来您可能想要做一些稍微不同的事情。

代替:

Delivery -> customer -> street address -> itinerary

在我看来,这样做更有意义:

Customer -> street address

delivery -> itinerary -> street address

在这个模型中,你可能有重复的信息,你可能需要在街道地址中有日期来指示它何时有效,但我并不觉得这是一个规范化问题,特别是考虑到已经解决的规范化问题姿势。但是从那里您可以轻松跟踪送货的客户,而在您的模型中,您不清楚是否可以跟踪给定送货的街道地址或行程。

关于postgresql - 数据库设计决策 : normalization or repetition?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19549120/

相关文章:

PostgreSQL 9.4 : index not working in a pattern search

sorting - Hive 数据记录的顺序是否对连接表很重要

python - 在 n 次函数调用后自动停止 scipy.optimize.fmin_bfgs (不是 BFGS 迭代!)

mysql - 使用 mysql workbench : Error 1005: Can't create table (errno: 150) 创建 CHAR 类型的外键时出错

MySQL/CakePHP 数据库设计问题

postgresql - PostgreSQL上的报告工具(如果重要的话,托管在Heroku中)

python - SQLAlchemy:带有 load_only、order_by 和 limit 的无效 SQL

javascript - 在行中对按其他列 ID 分组的一些其他列行值求和

python - 如何从 skopt/BayesSearchCV 搜索中绘制学习曲线

mysql - 如何处理此模型的可选字段?