存储经常添加/删除的列

Question

我有两个想法，用于存储我的网络应用的用户自定义/设置。可能有更多的方法可以做到这一点，我对新想法持开放态度。

您建议使用哪种方法来存储可能无法更改的设置/自定义设置？例如，本周有12个用户可以进行的自定义。下周我们可能会在短时间内添加一个新的。

所以，我可以：

1. 将设置存储为列（user_image_url为varchar，time_offset为int，background_color为varchar等），并以用户帐户为主键。我不喜欢每当有新设置时都要添加另一列的想法（并且可能有几十列），但我认为这是最简单，最快速，最明显的方式。
2. 创建一个仅存储帐户ID，设置ID和设置值作为varchar的表。所以，像(account_id, setting_id, value) values (1, 2, 'http://logos.com/yourlogo.png')之类的东西。我们的想法是将其与settings表一起存储setting_id。这个（我可以看到）的一大缺点是每个设置必须是相同的类型（varchar）。我不确定这是否会在以后咬我。

谢谢！

Answer 1

对于动态的“稀疏”值，您的第二个版本是存储值的可行方法。这称为实体 - 属性 - 值模型（EAV）。我发现它在混合安排中运行良好（足够）。也就是说，每个用户有一条记录，其中包含所有或大多数用户共享的大量公共信息。然后是一个带有特殊设置的单独表格。

EAV模型存在很多问题。性能可能是大型数据集的问题。表的大小要大得多，因为实体id和属性名称（或id）在许多行中重复。但是，一些重要的系统，如Wordpress使用这种方法。

一个很大的优点是你可以拥有超过4,096个属性 - 而4,096是MySQL的最大列数。我怀疑你会有那么多设置，但很高兴知道你可以在必要时绕过这个限制（并且在许多其他数据库中限制较低）。

最后，您可以通过设置多个列来修复类型问题 - 通常是varchar，float（某种类型）和datetime - 以及类型柱。这样，您可以直接存储值。如果你选择了varchar路线，请确保以ISO格式YYYY-MM-DD存储日期（如果愿意，可以省略连字符）。

Answer 2

选项1违反了关系数据库设计的第一范式。选项2是最好的方法。网上提供了许多可用的第一范式表的解释 - 这是我发现的最简单的：http://www.andrewrollins.com/2009/08/11/database-normalization-first-second-and-third-normal-forms/