我正在使用 Ruby on Rails，但我认为这个问题比这更广泛，通常适用于数据库设计。
何时将单个模型拆分为多个表是个好主意？例如，假设我有一个 User 模型，并且模型中的字段数量确实开始增加。例如，用户可以输入他的网站、他的生日、他的时区、他的等等。
拆分模型有什么优点或缺点吗，例如用户表可能只有登录和电子邮件等基本信息，然后每个用户都有另一个表，类似于 UserInfo，另一个是UserPermissions，另一个是 UserPrivacySettings 或类似的东西？
编辑：为了增加额外的光泽，大多数字段很少被访问，除了特定于它们的页面。例如，只有当有人点击进入用户的个人资料时，才会访问诸如生日之类的内容。此外，一些字段（很少访问）有可能非常大。大多数字段都有可能设置为空白或无。
【问题讨论】：
标签： database database-design models
通常，将具有一对一关系的事物放在同一个表中是个好主意。除非您的用户群包括女王或帕丁顿熊，否则用户只有一个生日，因此这应该是 USERS 表的一个属性。具有一对多关系的事物应位于单独的表中。所以，如果一个用户可以有多个隐私设置，一定要把它们分开。
如果我们想一次检索所有用户的信息，将一张表拆分为几张表会使查询变得更复杂或更慢。另一方面，如果我们有一组仅以离散方式查询或更新的属性，那么有一个单独的表来保存这些数据是一个不错的主意。
【讨论】：
这将是一个需要分析的情况。
当你发现这样一个表中的很多字段都是NULL，并且可以组合在一起（例如UserContactInfo）时，是时候考虑将信息提取到自己的表中了.
您希望避免一个包含数十/数百个字段且仅输入稀疏数据的表。
而是尝试对数据进行逻辑分组，并创建包含大部分已填充字段的主表。然后，您可以创建数据子集，几乎就像您在 UI 上表示它们一样（联系信息、个人兴趣、工作相关信息等）到单独的表格中。
【讨论】：
如果一行有很多列，则检索成本会更高，尤其是当您通常只需要一些字段时。此外，在单独的类中托管诸如地址组件之类的东西是 DRY 的一种情况。另一方面，如果您确实需要对象的所有字段，则执行复合查询需要更长的时间。
我通常不会为了使代码更具可读性而将类分布在多个表上（即没有像地址这样实际可重用的部分）。
【讨论】：