一个类和表应该彼此相同还是应该从查询中派生一个类？答案

【问题标题】：Should a class and table be identical to one another or should a class be derived from a query?一个类和表应该彼此相同还是应该从查询中派生一个类？
【发布时间】：2013-02-04 14:13:33
【问题描述】：

假设我正在制作电话簿。

班级朋友

->名字
->姓氏
->城市
->状态
->邮编
->电话

据我了解，最好的做法是在我的数据库中有两个表，不过对于这样的事情，FirstName、LastName、Phone 在一个表中，地址信息在一个单独的表中，然后使用 ForeignKey 连接它们。这样，如果两个朋友住在同一个地址，我就不会重复任何信息。

那么我应该使用 INNER JOIN 查询来设置课程吗？

我目前还没有确定一个框架，所以如果你也可以告诉我：

在 CakePHP 中，我可以使用 INNER JOIN 来创建一个类还是违反约定？如果不是这样，我会更好地使用 Laravel、Zend、Yii、Symfony 或 CodeIgniter 等不同的框架吗？

一个人可能有多个地点，例如一家公司有两个不同的办公室，或者一个朋友有一个夏天和冬天的家。

【问题讨论】：

我推荐阅读normalization。然后阅读when to denormalize。那么你仍然会有同样的问题:)
谢谢，我已经阅读了这两个方面的一些内容，并且肯定会继续阅读更多内容，尤其是如果有人推荐一本书。但我仍然想了解更多关于如何规划我的表以在类和框架中使用的信息。

标签： php class cakephp database-design

【解决方案1】：

对我来说，这是一个值得怀疑的标准化案例。是的，理论上你可以通过规范化地址来为自己节省一些冗余条目，但我真的会考虑在做出这个决定之前你将如何处理系统中的地址。地址是否始终是用户的属性（一对一关系），或者您是否打算实际进行某种地址管理，其中用户可以拥有多个地址？在前一种情况下，我可能不会标准化，而在后一种情况下，我肯定会。

这真的归结为地址作为一个支持对象，在你的系统中是否有任何意义，或者地址是否只是用户的一对一属性。

【讨论】：

是的，一个人可以有多个地点，例如一家公司有两个不同的办公室。我将编辑我的问题以澄清这一点。
您是否使用“规范化”作为“表分解”的同义词？在一对一的情况下，我根本看不到分解人员数据和地址数据在哪里完成任何规范化。
@WalterMitty “规范化”这个术语通常用于组织数据库中的表，以便数据不会以冗余方式重复。此规范化过程通常包括查看如何将大表中的数据拆分为多个较小的表，这些小表之间的关系用外键表示。
@Mike。好的。你像我一样以正式的方式使用 normalize。请注意，在您声明的第二种情况下，您正在使数据符合 2NF。在第一种情况下，就我所见，分解不会是“规范化”。
@WalterMitty 是的，我不建议只分解数据。在第一种情况下，我基本上是在声明将表与单个表中的所有列保持原样。只有当您需要为每个用户管理多个地址时，我才会将地址数据规范化为第二个表（具有一对多关系）。只有当我需要能够将多个用户与单个地址相关联（即每个地址查找多个用户）时，我才会在连接表中的用户和地址之间建立多对多关系。

【解决方案2】：

如果您计划让一个人一次与多个地址相关联，则只需将地址存储在单独的表中。如果每个人只有一个地址，只需将其放在主表中即可。我记得电话簿只将一个人与一个地址联系起来......

话虽如此，如果您确实使用多个表，您很可能会坚持使用一个类并执行连接。

【讨论】：

我根据回复编辑了问题 - 是的，一个人可能与多个地址相关联

【解决方案3】：

这样，如果两个朋友住在同一个地址，我就不会重复任何信息。

对于“精确”的数据可能很好，但地址为tend to be "fuzzy"。人们会以不同的方式表达它们，有时会拼写错误 - 如果发生这种情况，您应该使用哪个地址：数据库中已经存在的地址还是新地址？你怎么知道它们实际上是一样的，哪一个拼错了？最好将地址“隔离”起来，这样任何错误或变化对它们的来源人来说都是“本地的”。

从更哲学的角度来看：如果你这样做，为什么不“规范化”街道、邮政编码、城市、国家甚至（固定电话）电话号码？你可以用“精确”的数据来做到这一点，但对于地址，试图将这个概念推向极端只会让整个系统变得脆弱。

话虽如此，允许一个人拥有多个地址是完全合理的，方法是将地址放入通过 FK 连接的单独表中（地址引用人，而不是相反），否则只需将地址保留在同一张桌子。

【讨论】：