我在表中有一个列，用于存储枚举值。例如。大，中，小或一周中的几天。这将对应于网页上显示的文本或下拉列表中的用户选择。什么是最好的设计？
将值存储为int，然后可能有一个表中包含enums / int对应的字符串。
只需将值作为字符串存储在列中，以使查询更加不言自明。
在什么点/数量的数值最好使用整数或字符串。
感谢。
答案 0 :(得分：2)
假设您选择的RDBMS没有ENUM类型（为您处理此类型），我认为最好在值可以更改时（无论是值还是数量）直接使用id而不是字符串。
您可能认为一周中的几天不会改变，但如果您的应用需要添加国际化支持，该怎么办？ （或者一个邪恶的跨国公司决定在控制世界之后重新命名它们？）
此外，大，中，小分类可能会在一段时间后发生变化。你认为大多数价值观都无法改变，可能会在一段时间后改变。
因此，主要是为了预测更改原因，我认为最好使用ID，您只需要更改转换表，一切都可以轻松完成。对于i18n，您只需展开转换表并自动提取正确的记录。
最有可能（它将取决于各种因素）整体的表现会更好，至少在所需的存储量方面。但出于性能原因，我不会这样做，出于灵活性原因，我会这样做。
答案 1 :(得分：1)
这是一个有趣的问题。当然，你必须在这里考虑性能目标。如果你不想追求速度，必须使用int。数据库可以比Strings更好地索引整数，尽管我必须说它根本不是一个糟糕的性能损失。
示例是Oracle数据库本身，他们可以在系统表上使用大型大写枚举作为字符串。像USER_ALLOCATION_TYPE这样的东西是常态。就像你说的那样，字符串可以更“可扩展”并且更具可读性，但无论如何在代码中你最终会得到：
静态最终字符串USER_ALLOCATION_TYPE =“USER_ALLOCATION_TYPE”;
取代
静态最终int USER_ALLOCATION_TYPE = 5;
因为你要么这样做，你最终会得到所有这些字符串文字，只是为了某人去那里而错误地放置一个字符！ ：）
在我的公司，我们使用带有整数主键的表;所有的表都有一个串行主键，因为即使你不认为你需要一个，你迟早会后悔。
如果您正在描述我们所做的是我们有一个表（PK Int，描述字符串），然后我们使用连接查看主表以获取描述，这样我们就可以看到连接字段描述如果我们必须并且我们保持表现。
此外，使用单独的描述表，您可以获得有关您永远不会想到的那些ID的EXTRA信息。例如，假设用户可以访问组合框中的某些字段，当且仅当他们具有此类属性时才能访问。您可以使用描述表中的额外字段来存储它以代替特殊代码。
我的两分钱。
答案 2 :(得分：0)
继续你的第一个例子。让我们说你创建一个查找表：大小。它包含以下列： Id - 主键+标识 名称 - varchar / nvarchar
表中有三行，Small，Medium和Large，如果按顺序插入，则值为1,2,3。
如果您有另一个使用这些值的表，您可以使用标识值作为外键...或者您可以创建第三列，这是三个值的简写值。它将具有值S，M＆amp; L.您可以将其用作外键。您必须在列上创建唯一约束。
就下拉列表而言，您可以使用其中任何一个作为幕后的值。
您也可以创建S / M / L值作为主键。
关于何时最好使用ints vs strings的另一个问题。关于这个问题可能存在很多争论。很多人只喜欢使用身份值作为主键。其他人说使用自然键更好。如果您没有使用身份作为主键，那么确保您拥有主键的良好候选者（确保它始终是唯一的并且值不会更改）非常重要。
答案 3 :(得分：0)
我也会对人们对此的看法感兴趣，我总是将枚举存储在查找表中，然后在引用枚举的任何数据表中，我会存储ID并使用FK关系。在某种程度上，我仍然喜欢这种方法，但是将字符串值直接放在表格中有一些简单明了的事情。
纯粹按大小来说，int是4个字节，其中字符串是n btyes（其中n是字符数）。查找中的最短值是5个字符，最长的是6个，因此存储实际值最终会占用更多空间（如果这是一个问题）。
按性能划分，我不确定int或varchar上的索引是否会返回速度/优化/索引大小的任何差异？