从数据库生成枚举，反之亦然
本文关键字：反之亦然 枚举 数据库 | 更新日期: 2023-09-27 18:07:11
我正试图找出哪是"正确"的方式来做到这一点。我在我的数据库中有一堆查找表，并希望在这些值之上放置一个枚举，因此，在编码时，它更容易阅读(以及不使用硬编码值)。
我想知道我是否应该根据现有的枚举生成我的表值，或者我是否应该从我的表的值生成我的枚举。
编辑
根据前两个注释，这里有一些澄清:
值的更改频率可能相当频繁，因为它们是动态的。也就是说，在添加任何一种方式之前都需要进行编译，因为需要更新枚举以公开新值。
这个需求的主要原因是因为我们不想把人们束缚在一个特定的值列表上，我们希望应用程序能够在需要的时候添加新的条目。
在过去，我们从枚举中生成数据，但我怀疑自己
我们通常从数据库生成枚举。我们使用codessmith，它允许我们创建项目文件，可以根据需要轻松地重新生成枚举。
我们偶尔也会采用另一种方法，通常是为了报告目的(当保留现有的enum值时)。
当然，也有不持久化值的枚举。
一般来说，从数据库生成枚举的唯一原因是代码需要基于它们做出决策。如果你只想填充一个ComboBox并保存用户的选择，就不要生成enum。
显然，基于值可以改变的枚举(或字符串)做出决策是很脆弱的。您可能需要考虑在数据库模式中包含过期日期(或"from"answers"through"日期)，这样就不会删除现有值。在填充UI选择器时过滤过期值。这也使引用完整性更容易实现。
与c#中一样，必须注意枚举值可能超出预期范围。在你的switch上包含一个default
我们提供了帮助类来创建缓存查找列表，使其更易于使用。
我不主张走这条路。如果有必要，我们就是这样做的。
还有第三种选择，你有一个明确的模型，它描述了你所需要的详细程度的模式，然后你生成两个数据&;来自该模型的模式。
关于你的问题，我认为你应该做的是在你的背景下思考这个问题，列出每个选择的利弊，然后决定什么对你和你的业务最有意义。
我已经为不同的应用程序使用了这三种策略，我个人更喜欢的一种是有一个显式的模型，但取决于上下文。
很抱歉我说的不太清楚，但我认为对于这类问题，有一条黄金法则在任何情况下都适用