Database 数据库规范化

我是数据库设计的新手，我读了很多关于规范化的书。如果我有三张桌子：住宿、火车站和机场。我会在每个表中都有地址列，还是其他表引用的地址表？是否存在过度正常化的情况

---

谢谢

我认为在这种情况下，在每个表中都有地址列是可以的。你几乎没有一个地址会被使用两次以上。大多数地址将仅用于每个实体的一个地址

但在一张额外的表格中可能会有街道、城市、国家的名称

---

最重要的是，每个火车站、住宿区和机场可能只有一个地址，因此是n:1关系。

对于地址，我几乎总是创建一个单独的地址表。不仅用于规范化，还用于存储字段的一致性

至于过度规范化，绝对有！很难给你关于什么是和什么不是过度规范化的指导，因为我认为它主要来自经验。然而，按照书中关于标准化的每一个层次，一旦开始很难看到事情的进展，你可能已经走得太远了

也可以查看所有示例/示例数据库。它们会给你一个很好的指示，告诉你什么时候应该分割数据，什么时候不应该

---

另外，要清楚地了解您存储的数据的类型和数量，以及访问速度等。由于许多性能和可伸缩性原因，许多现代web软件正在完全非规范化。这是值得研究的，因为你应该和不应该去正常化的原因和时间。

就个人而言，我会选择另一张桌子

我认为它使设计更简洁，使地址报告更简单，并使您需要对地址模式进行的任何更改更容易

如果以后需要对其进行非规范化，则始终可以创建两个视图，其中包含火车站和机场信息以及所需的任何地址信息

我会在每个表中都有地址列，还是其他表引用的地址表

机场、火车站和住宿是否都有不同的地址格式

单个地址表可以最大限度地减少处理地址所需的工作—套件、RR、邮政编码/邮政编码、州/省

是否存在过度正常化的情况

---

标准化有不同的级别。我只遇到了我认为糟糕的设计而不是规范化的问题。

< P>如果您使用Oracle 9i，您可以在表中存储地址对象。这将消除对地址格式的（合理的）担忧。

这并不是我所理解的标准化。您似乎不是在谈论消除冗余，而是讨论如何对存储或数据模型进行分区。我假设住宿、火车站和机场的地址示例都是不相交的

据我所知，只有当你开始按照这些思路思考时，这才是正常化。邮政编码在功能上取决于街道地址，因此应该在其自己的表中进行分解

在这种情况下，这可能是可取的，也可能是不可取的，这取决于上下文。如果您管理记录并确保其正确性，则可能是可取的；如果用户可以更新自己的记录，则不太可取

---

一个相关的问题是？

如果您有一个对性能非常敏感的项目/功能，在某些情况下，对数据库进行非规范化可能是明智的。但是，由于各种原因，这可能会导致维护问题。您可能希望使用缓存表复制数据，但这也有缺点。这实际上是一个个案基础，但在正常实践中，数据库规范化是一件好事。我看到的99%的非规范化数据库不是设计的，而是开发人员的误解/错误。

我同意S.Lott的观点，并想补充：

一个好的答案取决于你已经知道了什么。然而，关系数据库理论的基本“数学”定义了非常明确的规范化级别。当你达到最终的正常形式时，你就不能再正常化了

根据您想用三个实体建模的内容以及识别它们的方式，您可以提出非常不同的概念数据模型，所有这些模型都可以用混合的标准形式表示——或者完全不规范化（例如，一个表用于所有数据，其中包含描述符和空孔……）。 考虑你把你的三个实体归一化到最终的正常形式。我现在可以引入一个新的需求，或者用例，或者扩展，如果你看一下它的内容，它会给一个到现在为止的描述性属性一个某种程度上有序的，或者引用的，或者结构化的属性。然后，模型应该表示这种行为，以前作为属性的对象最好是由其他实体引用的单独实体

过度正常化？只有在这个意义上，您才能规范化给定的模型，使其在给定的DB平台上存储或处理变得效率低下。根据那里可以有效处理的内容，您可能希望对某些方面进行非规范化，以冗余换取速度（数据仓库dbs一直都在这样做）和洞察力，反之亦然

到目前为止，我所看到的所有（正在工作的）db设计都有一个相当规范化的概念数据模型，在逻辑和/或物理数据模型级别（用Sybase PowerDesigner术语来说）进行了相当多的非规范化，以使模型“可管理”——要么如此，要么不起作用，也就是说，由于维护问题很快就变成了kingsize，所以失败了。

当你说“地址”时，我想你指的是一个完整的地址，比如街道、城市、州/省，可能还有国家和邮政编码。那是四五