对我来说，经典的看法是将枚举值（OrderStatus，UserTypes等）作为查找表存储在数据库中。这使我可以在数据库中执行数据完整性，防止错误值或空值等。枚举数据库中的DB或NO枚举
但是越来越多，这感觉像是对我不必要的重复。我不仅需要为这些值创建表（或者有一个笨拙的中央查找表），但是如果我想添加一个值，我必须记住将它添加到2（或更多，计算生产，测试，实时数据库），而且事情可能很容易失去同步。
我仍然很难放开查找表。
我知道可能存在一些情况，其中一个比另一个有优势，但是你的一般想法是什么？
我已经做了两个，但我现在更喜欢在代码中的类中定义它们。
新文件不需要花费任何费用，而您在数据库中查找的好处应视为业务规则。
此外，我有一种厌恶的方式来保存数据库中的数据，这些数据实际上并没有改变。看来一个枚举符合这个描述。我有一个国家查找表是没有意义的，但是一个国家枚举类对我来说是有意义的。
我把它们放在数据库中，但我真的不能防守为什么我这样做。它只是“看起来不错”。我想我通过说检查数据库总是有一个“正确”的枚举类型。
如果必须维护，我会将它们留在数据库的查找表中。即使我认为他们不需要维护，我仍然会去查找表，这样如果我错了，这不是什么大问题。
编辑：
我要澄清的是，如果枚举不是DB模式的一部分，那么我将它留在代码。
什么不会被认为是数据库模型的一部分？ – 2009-09-24 19:45:51
任何不作为记录条目的一部分存储在数据库中的东西。 – klabranche 2009-09-24 19:48:56
架构的依赖应该存储在数据库本身，以确保您的体系结构的任何变化可以透明地轻松地执行到应用程序..
我喜欢枚举，因为它强制早期绑定代码中的值，使异常不是由缺失值造成的
如果您可以使用能够将整数列的关联引入枚举类型的代码生成也是有帮助的，这样在业务逻辑中您只需处理易记忆的枚举值。
认为它是一种文档形式。
如果您已经在使用dB的代码中正确记录了枚举常量，那么您是否真的需要一套重复的文档（要使用和维护）？
在思考它的时候，我想它归结为将其视为数据库驱动的应用程序或使用数据库来存储它的状态的应用程序。我的意思是将数据库视为一个独立的实体，可能被其他应用程序或服务使用，在这种情况下，数据完整性至关重要。与使用db作为应用程序的简单数据存储，依靠应用程序来执行数据完整性规则。在这种情况下，关系可能甚至不需要。 – 2009-09-26 15:04:02
你如何处理确保没有行的枚举值无效？只使用访问数据库的代码？ – 2009-09-24 19:27:57