【发布时间】：2012-11-24 16:13:03
【问题描述】：
我正在为一家在线零售店设计 ERD 图。我有一个客户表，其中存储了所有相关详细信息。我还有一个仅包含的客户登录详细信息表；电子邮件和密码字段。我能看到的唯一关系是一对一的，电子邮件是两者之间的链接。
我的问题是我最好将这张桌子吸收到客户的桌子上吗？或者将其分开有什么好处？
感谢任何帮助，因为数据库不是我的强项
【问题讨论】：
标签： database-design erd
【发布时间】：2012-11-24 16:13:03
【问题描述】：
是的，对于这样的一对一，我希望将所有详细信息都放在一张表中。
一些例外情况可能是：
性能。如果有数十万用户，您会希望主表尽可能“薄”，有时这意味着将单个细节移到一对一的表中。
数据库中的安全性。将密码放在与其他用户详细信息不同的字段中，可以让您在保护该表方面投入更多工作，而不会减慢或阻止对用户详细信息表的访问。用户详细信息将包含个人信息，但几乎没有什么比密码更重要的了，它使冒名顶替者可以访问实际做事（包括轻松找到更多个人信息只是假登录）。
ERD 的安全性。由于您的问题在标题中有 ERD，因此如果 ERD 在单独的表中，则显示 ERD 具有实际省略表名和列名和密码的能力会容易得多，并且在共享 ERD、进行演示时可能需要这样做，等等
需要多次登录。 Stack Exchange 之类的网站允许您将多个帐户关联到一个主“登录”。在这些场景中，将用户名密码分开，因为这实际上是一对多的关系。因此，如果您确信一对一的关系永远不会改变，并且/或者您正在开发一个在实际制作功能之前不预测功能的敏捷流程，那么您就不需要单独使用它。
【讨论】：
-
当然。添加了一个关于 ERD 的更多内容。
如果您的所有列都与客户直接相关并且它们不会造成冗余（重复行），那么请将它们放在同一个表中。例如以下字段：姓名、家庭、电子邮件和密码都应该在同一个表（实体）上，这是您的用户，因为它们与用户实体密切相关。
如果您假设存储了有关您的用户的地址信息，包括街道、城市、州等。那么有一个 Address 实体与用户之间的一对多关系是合乎逻辑的。
最后一件事，当您存储有关用户的各种数据时，规范化的想法非常棒，因此只有在这种情况下才有意义。过度规范化也会对查询的性能造成额外的开销，毕竟规范化的次数越多，选择查询运行的速度就越慢。
【讨论】：