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