Mysql 由于清晰性、可维护性而拆分表格？ 仅仅为了清晰性、可维护性而拆分一个表有意义吗？

我有一个经典的用户表，其中存储的数据如下

userid  name        userName        email            lastlogin      
-------------------------------------------------------------- 
1       Buffer      Stack           s@overflow.com   1312565858

此外，我需要以每个用户为基础保留设置。这些设置将主要覆盖布尔字段，可能如下所示

quickSave   showInfo    showOnlineStatus    sendNews         sendRemainder      
--------------------------------------------------------------------------- 
0           1           1                   1                0

尽管如此，我至少看到了两种（通常的）选择

• 将各个设置直接添加到用户表中
• 创建一个单独的设置表并保持该关系

我对事物结构的倾向使我倾向于后者

问题:

---

如果表与上述严格1对1相关，那么拆分表是有效的方法吗？如果是，那么何时拆分表有阈值吗？

我会选择第三个选项：

创建一个

authentication

表，该表存储诸如

lastLogin

、

userName

等信息，然后将所有这些列添加到

user

表中

此信息确实描述了用户，因此为了维护数据库实体，我将向

user

表中添加列

另一方面，如果一个实体周围有一个定义良好的边界，你可以将其描述为

设置
，那么1对1的关系就没有问题。
我认为“这取决于”是唯一可以给出的完全正确的答案。

-这个问题有点像问“第六范式比第五范式好吗？”

单独表格的好处主要是灵活性：

-以最小影响进行设计更改的能力

例如，您可能希望开始维护旧值和当前值，所有内容的耦合越不紧密，就越容易进行更改

但最极端的版本是每个字段都有一个单独的表格。我看不出有多少人认为这是个好主意。特别是从可维修性的角度来看,；它可能很灵活，但拥有10亿张表远不容易理解



关于何时使用单独的表，我的基本经验法则是，字段在逻辑上可以被认为是显著不同的。关于用户（姓名、地址等）及其应用程序设置（快速保存等）的详细信息对我来说似乎非常适合。这在这里可能无关紧要，但这样可以避免争用，即一个进程正在尝试处理用户地址，而另一个进程正在更新用户应用程序设置



这就是说，如果您发现在数据可用之前总是将两个表连接在一起，这就强烈表明它们不应该分开。我怀疑您可能通过在其中一个表中查找用户的登录详细信息，然后连接到另一个表来使用这些表



从这个问题的狭隘角度来看，我个人对你的选择？

-将它们放在一张表中

-直到你找到不去的理由

您可以在以后将它们分离出来，并在视图中重新组合它们，以保持代码兼容性。
我的首选项是基于读/写活动的spilt

比如说

如果您的用户表只是不经常写入，但经常读取，我会将其与可能更频繁写入的设置表分开

如果您使用的是myISAM表，这一点更为重要，因为它们具有表级锁定。InnoDB使用行级锁定（但您仍然可以将表作为一个整体进行锁定），但仍然可以选择基于读/写频率移动存储，这很好。数据库理论可能会很快失控。答案是在做决定时要合理

诚然，核心DBA会争辩说，电子邮件不属于用户表，因为用户可能有多个…，可能会更改…，您可能需要保留历史记录…等等。事实上，这很愚蠢。如果你的应用程序只需要一个电子邮件地址，那么它就适合你。关键是，做出这些决定不仅仅是理论上的

类似地，在实际操作中，您提出的任何一种解决方案都会起作用。没有人会在表现上有显著的不同。如果是我，我可能会将其保存到一个单独的表中，该表包含所有用户首选项，还包括其他UI元素。同样，这取决于你和你的需要。
你需要权衡。您当前有一系列与用户一对一的关系。通过将它们保留在同一个表中，可以使它们更易于查询，但当您要添加另一个字段时，查询会更加困难。通过添加设置表，您可能会使数据更难查询，并且可能会根据设计造成性能噩梦

您可以通过两种方式创建表，即创建一个与用户呈一对一关系的表。如果您的users表已经很宽，并且在大多数users表的查询中不需要这些设置，那么这是很好的。如果你现在的情况是1比1，但你希望它们以后会变成1比多，这也会很好。但是，如果需要添加新的设置，您仍然需要更改表

另一种方法是创建一个EAV表，其中包含诸如Userid、SettingType和Value之类的内容。对于查询大多数数据来说，这是一种非常糟糕的存储方法。现在，您不需要查询一个表，而是需要查询第一个表并多次连接到第二个表以获取所有数据。你甚至不知道要参加多少次。这种结构应该谨慎使用，决不能用于您事先知道需要的设置。它的正确用法是用于客户端定义的字段。只有当你希望很少使用它的时候。它是性能杀手。
因此，您的建议是使用两个表（用户和身份验证）或三个表（用户、身份验证和身份验证）