问好的数据库设计:枚举值:int还是string？

EN

假设您选择的RDBMS没有ENUM类型(它会为您处理此问题)，我认为当值可以更改(值或数量)时，最好使用in而不是字符串。

您可能认为星期几不会改变，但是如果您的应用程序需要添加国际化支持呢？(或者一个邪恶的跨国公司在控制了世界之后决定给它们重新命名？)

此外，这种大、中、小的分类可能会在一段时间后发生变化。大多数你认为不能改变的价值观，可能会在一段时间后改变。

因此，主要是为了预测更改的原因，我认为最好使用it，您只需更改转换表，一切都可以轻松地工作。对于i18n，您只需展开转换表并自动提取适当的记录即可。

很有可能(这取决于各种因素)int将会表现得更好，至少在所需的存储量方面是这样。但我不会因为性能的原因而使用整型，我会因为灵活性的原因而使用整型。

这是一个有趣的问题。当然，在这里你必须考虑到性能目标。如果你不想追求速度，int是必须的。数据库可以比字符串更好地索引整数，尽管我必须说这并不是一个糟糕的性能损失。

例如Oracle数据库本身，他们可以在系统表中使用大写的枚举作为字符串。像USER_ALLOCATION_TYPE这样的东西或类似的东西是常态。就像你说的，字符串可以更“可扩展”，更具可读性，但在任何情况下，在代码中你都会得到：

静态最终字符串USER_ALLOCATION_TYPE="USER_ALLOCATION_TYPE"；

代替

静态final int USER_ALLOCATION_TYPE=5；

因为您要么这样做，要么最终得到所有这些字符串文字，它们都渴望有人去那里，并将字符放错了位置！:)

在我的公司中，我们使用带有整数主键的表；所有的表都有一个串行主键，因为即使你不认为你需要一个，迟早你也会后悔的。

在你描述的情况下，我们所做的是，我们有一个包含(PK Int，Description String)的表，然后我们通过joins对主表进行查看，以获得描述，这样我们就可以在必要时看到连接的字段描述，并保持性能。

此外，使用单独的description表，您可以获得有关那些您永远不会想到的ids的额外信息。例如，假设用户可以访问组合框中的某些字段，当且仅当他们具有这样的属性时。您可以在description表中使用额外的字段来代替即席代码。

我的两点意见。

下面是你的第一个例子。假设您创建了一个查找表: Sizes。它包含以下列: Id -主键+标识名称- varchar / nvarchar

如果按照值1、2、3的顺序插入，表中会有三行，分别是Small、Medium和Large。

如果您有另一个表使用这些值，您可以使用identity值作为外部key...or，您可以创建第三列，它是这三个值的缩写。它将具有S，M& L值。您可以将其用作外键。您必须在列上创建一个唯一的约束。

至于下拉列表，您可以使用其中任何一个作为幕后的值。

您还可以创建S/M/L值作为主键。

对于你的另一个问题，什么时候最好使用int和字符串。在这个问题上可能有很多争论。很多人只喜欢使用身份值作为他们的主键。其他人说使用自然密钥更好。如果您没有使用身份作为主键，那么重要的是要确保您有一个很好的主键候选者(确保它始终是唯一的，并且值不会改变)。