我正在开发一个定制的特定CMS项目。在前端，许多领域将有预先填充的选择。但是，对于这些字段，需要有一个“其他”选项，允许用户输入文本字符串。项目范围不希望将这些新的“其他”值添加到预先填充的列表中（现在或进一步）。这只是一个例外。项目范围坚持在整个应用程序中实现的这种灵活性。
我有包含所有这些预先填充的列表的数据库表。我将这些表称为列表表（全部以“list _”开头）
我的问题是存储用户所做的选择。如果不是为了这种灵活性，我会将值作为外键存储到适当的列表中。但是，这些字段存储值（字符串）而不是密钥是有意义的。缺点是索引（次要），内容控制（次要），全局更新，即更改列表中的值不会反复通过系统，除非编码为（相当大的问题）。
我还要提到将数据存储为值而非密钥使得编程和函数也变得更加简单（我正在编写一个服务层，它减少了连接并允许函数更通用）。
存储为值（字符串）而不是键是团队想要去的路线。
这样做我犯了一个大错误吗？或者这是相当普遍的？还有其他需要考虑的问题吗？
替代品： 我的替代方案是将“其他”字符串添加为列表中的新行，并使用字段使其“隐藏”。
答案 0 :(得分：1)
通常，如果您可以存储外键而不是值，那么它为您购买的强制一致性通常会使事情变得更简单。
然而，“要求”使得听起来好像这不是一个选项，这使得它“感觉”好像数据中存在不一致。听起来目标是在一个字段中存储两种类型的数据：预定义值或用户选择的值，并且这两个值具有不同的含义。在不了解系统的情况下，很难肯定地说，但这可能会使某些类型的查询更难写（但并非不可能）。
如果该值实际上只是一个文本值，并且预先填充的列表提供了一种简单的方法来进行选择，那么存储文本值似乎没问题。但是，这个问题听起来好像是将意义附加到查找表中的值。如果是这样，则存储外键可以产生更稳健的解决方案。但是，如果选择“其他”，则可能需要将“其他”值（及其关联的外键值）添加到查找表中，并将另一个自由格式文本字段添加到表中以存储实际文本。
答案 1 :(得分：0)
首先，您所描述的方式中“列表”表的概念感觉模糊不清。它似乎表明对这些实体的规范没有完全理解或审查。您不应该将“列表”实体与非“列表”实体区分开来。
其次，听起来你遇到的问题是当用户可以选择输入自己的值而不是可能出现在下拉列表中的项目时。在那种情况下，我将有一个特殊的外键值代表“自定义”，然后我会显示一个文本框供用户输入自定义值。我将自定义值存储在与FK值不同的列中。每当用户选择非自定义选项时，我都会将自定义条目归零（理想情况下，这将通过Check约束强制执行，但MySQL不会遵守它们，因此您必须使用触发器）。通过这种方式，您的CMS可以首先查看是否存在自定义值，然后查看FK中的值。同时拥有FK和自定义文本列的优点是，您可以轻松更改父表的构成（添加属性，添加值，调整值等），而不必影响子表。