我的实践表明，一般的企业应用程序有很多实体，其性质与基本枚举相对应。例如，我们可能有一个Order实体，它可能具有诸如“OrderType”，“OrderStatus”，“Currency”等字段，引用相应的实体，它们只不过是绑定到要引用的键的文本名称。你在你的数据应用中使用枚举吗？
使用枚举在这里看起来很自然。但实体必须在设计时在应用程序代码中定义，对吗？虽然我们需要能够在运行时CRUD枚举值变体，并在服务器端SQL查询（如存储过程和视图）中使用枚举。
你在这个问题上的做法和想法是什么？
我特别感兴趣的是C＃4，linq和T-SQL。
从某种意义上说，C＃枚举类似于面向对象的类层次结构。如果您声明枚举Choice与替代品One和Two，它有点类似于声明具有基类Choice和两个派生类型（One : Choice和Two : Choice）的类层次结构。
一个区别是，枚举不是可扩展的（如果你需要添加的情况下，你需要修改的声明，而如果你需要的情况下添加到一个类层次结构，只需定义一个新的继承类型）。
第二个区别是枚举的选项不能携带附加数据 - 如果您声明了类层次结构，则可以将其他字段存储在One大小写中（例如）。
如果没有这两个“limiations”，你可以考虑使用枚举来表示应用程序中的实体（实际上，函数式语言具有构造类似于这些“更强大”枚举和使用它的这几样东西） 。
但是，由于C＃枚举是非常简单的，他们大多是用于表示值独立于特定域的，或者需要更多的一般的编程值。例如：
enum TriState { True, False, Undecided }
这可能是相当有用的类型，但它与任何特定域都没有直接关系。
我使用的数据库值的枚举不应该由用户创建或更改，并且如果存在基于该值的特殊逻辑。货币不是一个很好的例子，除非您的枚举中包含所有货币，并且接受在新货币出现或不推荐使用时您必须重新编译您的应用程序。如果基于OrderStatus的系统中有逻辑，OrderStatus可能是一个很好的例子。无论如何，应该注意的是，如果您确实创建了一个枚举来表示数据库值，那么应该重新编译应用程序，如果需要创建此表中的新值，则应谨慎使用此实践。
在我要去模仿数据库值与枚举的情况下，我用枚举值的名称作为表的主键，它被传递到外键值。也就是说，当我保存到数据库时，我将通过myEnumVal.ToString()。我有几个原因。首先，它要求增加一个值更加慎重。如果我使用数字值作为主键，则暗示我正在使用代理键，并且可以轻松地添加其他值。当其他开发人员看到使用名称作为主键的列时，他们更有可能认为该值不是任意的。其次，它使数据库代码更易于阅读。您会收到诸如Where OrderStatus = 'Active'而不是Where OrderStatus = 1的查询。