就性能和“可读性/良好的编码风格”而言，在 DB 层上表示整数（或一般的任何数字数据类型）的（Java）枚举（固定的常量集）的最佳解决方案是什么与字符串表示。
警告：有些数据库系统直接支持“枚举”，但这需要使数据库枚举定义与业务层实现保持同步。此外，这种数据类型可能并非在所有数据库系统上都可用，并且语法也可能不同 => 我正在寻找一种易于管理且可在所有数据库系统上使用的简单解决方案。 （所以我的问题只涉及数字与字符串的表示。）
在我看来，常量的数字表示存储起来非常有效（例如，仅消耗两个字节作为整数）并且在索引方面很可能非常快，但难以读取（“0”与“1”等）..
String 表示形式更具可读性（与“0”和“1”相比，存储“启用”和“禁用”），但会消耗更多存储空间，并且很可能在索引方面也较慢。
我的问题是，我错过了一些重要的方面吗？您建议在数据库层上使用什么枚举表示。
非常感谢！
【问题讨论】：
在大多数情况下，我更喜欢使用简短的字母数字代码，然后使用带有扩展文本的查找表。必要时，我从数据库表中动态地在程序中构建枚举表。
例如，假设我们有一个应该包含交易类型的字段，并且可能的值是 Sale、Return、Service 和 Layaway。我会创建一个包含代码和描述的事务类型表，使代码可能是“SA”、“RE”、“SV”和“LY”，并使用代码字段作为主键。然后在每个交易记录中，我都会发布该代码。这比记录本身和索引中的整数键占用更少的空间。它的具体处理方式取决于数据库引擎，但它的效率不应低于整数键。而且因为它是助记符，所以非常易于使用。您可以转储记录并轻松查看值是什么，并可能记住哪个是哪个。您可以在用户输出中显示无需翻译的代码，并且用户可以理解它们。实际上，这可以让您获得优于整数键的性能：在许多情况下，缩写对用户有好处——他们经常希望缩写保持显示紧凑并避免滚动——因此您不需要加入事务表获得翻译。
我绝对不会在每条记录中存储长文本值。就像在这个例子中一样，我不想放弃事务表并存储“Layaway”。这不仅效率低下，而且很有可能有一天用户会说他们希望将其更改为“Layaway sale”，甚至是“Layaway”之类的细微差别。然后，您不仅需要更新数据库中的每条记录，还必须在程序中搜索该文本出现的每个位置并进行更改。此外，文本越长，程序员就越有可能拼写错误并产生难以理解的错误。
此外，拥有事务类型表可以方便地存储有关事务类型的附加信息。从来没有写过这样的代码：“如果whatevercode='A'或whatevercode='C'或whatevercode='X'然后......”无论是什么使这三个代码与所有其他代码有所不同，请放置一个字段它在事务表中并测试该字段。如果您说“嗯，这些都是与税收相关的代码”或其他什么，那么可以，创建一个名为“tax_related”的字段，并将每个代码值适当地设置为 true 或 false。否则，当有人创建一个新的交易类型时，他们必须查看所有这些 if/or 列表，并找出该类型应该添加到哪些，不应该添加到哪些。我读过很多令人费解的程序，我不得不弄清楚为什么某些逻辑适用于这三个代码值而不适用于其他代码值，当你认为第四个值应该包含在列表中时，很难判断它是否是丢失是因为它在某些方面确实不同，或者如果程序员犯了错误。
我不创建转换表的唯一类型是列表非常短，没有额外的数据要保留，而且从宇宙的性质来看，它不太可能永远改变，所以值可以安全地硬编码。像真/假或正/负/零或男性/女性。 （嘿，即使是最后一个，看起来很明显，有些人坚持我们现在包括“变性”等。）
有些人教条地坚持每个表都有一个自动生成的顺序整数键。在许多情况下，这样的键是一个很好的选择，但对于代码列表，我更喜欢短字母键，原因如上所述。
【讨论】：
我会存储字符串表示，因为这很容易关联回枚举并且更加稳定。使用 ordinal() 会很糟糕，因为如果您在系列中间添加一个新枚举，它可能会发生变化，因此您必须实现自己的编号系统。
就性能而言，这完全取决于枚举的用途，但开发一个带有转换的完全独立的表示而不是仅仅使用自然字符串表示很可能是一种过早的优化。
【讨论】：