从数据库生成枚举还是反之亦然？
我试图找出执行此操作的“正确”方法。我的数据库中有一堆查找表，并且希望在这些值之上放置一个枚举，以便在编码时更易于阅读（并且不使用硬编码值）。
我想知道是否应该根据现有枚举生成表值，或者是否应该根据表值生成枚举。
编辑
根据前几条评论，这里有一些说明：
值更改的频率可能相当频繁，因为它们的目的是相当动态的。话虽如此，在以任何一种方式添加这些内容之前都需要进行编译，因为需要更新枚举以公开新值。
这种需求的主要原因是我们不想将人们束缚在特定的值列表上，我们希望应用程序能够在需要时添加新条目。
过去，我们通过枚举生成数据，但我自己又怀疑了
I'm trying to figure out which is the the "correct" way to do this. I have a bunch of lookup tables in my database and would like to place an enum on top of those values so, when coding, it's easier to read (as well as not use hard-coded values).
I'm wondering if I should generate my table values based on an existing enumeration or if I should generate my enumeration from my table's values.
EDIT
Based on the first couple of comments, here are some clarifications:
Frequency of changes to the values could be rather frequent as they are intended to be rather dynamic. That being said, a compile will be necessary before adding any of these either way, because the enumeration needs to be updated to expose the new values.
The main reason for this need is because we don't want to tie people down to a specific list of values, we would like the applications to have the ability to add new entries as and when they need to.
In the past, we have generated the data from enumerations, but I'm second guessing myself
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
还有第三种选择，您有一个显式模型，它以您需要的详细程度描述模式，然后生成数据和数据。该模型的架构。
关于您的问题，我认为您应该做的是在您的背景下考虑问题，并列出每种选择对您的利弊，并决定什么对您和您的业务最有意义。
我已经针对不同的应用程序使用了所有三种策略，我个人更喜欢的是拥有一个明确的模型，但取决于上下文。
抱歉，我说得很模糊，但我认为对于这类问题，有真正的黄金法则，它始终适用于所有情况。
There's also a third option in that you have a explicit model which describes the schema in the level of detail you require and then you generate both data & schema from that model.
Regarding your question I think what you should do is thinking about the problem in your context and list pros/cons for you with each alternative and decide on what makes most sense for you and your business.
I have worked worked with all three strategies for different applications, the one I personally prefer is having an explicit model buts depending on the context.
Sorry for being fuzzy but I think for these kind of questions there's real golden rule which always applies in all cases.
我们通常从数据库生成枚举。我们使用 CodeSmith，它允许我们创建可以根据需要轻松重新生成枚举的项目文件。
我们偶尔会采用另一种方式，通常是出于报告目的（当现有枚举值保留时）。
当然，我们有一些枚举，其值永远不会持久。
一般来说，从数据库生成枚举的唯一原因是代码是否需要根据它们做出决策。如果您只想填充 ComboBox 并保留用户的选择，请不要生成枚举。
显然，根据值可以更改的枚举（或字符串）做出决策是脆弱的。您可能需要考虑在数据库架构中包含到期日期（或“起始日期”和“截止日期”），以便不会删除现有值。填充 UI 选择器时过滤过期值。这也使得更容易实现引用完整性。
与 C# 中一样，您必须注意枚举值可能会超出预期范围。在您的
开关上添加一个默认。我们提出了用于创建缓存查找列表的帮助程序类，使这些列表更易于使用。
我并不提倡走这条路。如果你必须这样做，我们就是这样做的。
We usually generate enums from the database. We use CodeSmith, which allows us to create project files that can easily regenerate the enums as needed.
We've gone the other way occasionally, usually for reporting purposes (when existing enum values are persisted).
And, of course, we have enums whose values are never persisted.
In general the only reason to generate enums from the database is if code needs to make decisions based on them. If you just want to populate a ComboBox and persist the user's choice, don't generate an enum.
Obviously making decisions based on enums (or strings) whose values can change is fragile. You may want to consider including expiration dates (or "from" and "through" dates) in your database schema, so that existing values are not deleted. Filter expired values when populating UI selectors. This also makes it easier to have referential integrity.
As always in C#, you have to be aware that enum values may fall outside of the expected range. Include a
defaulton yourswitch.We came up with helper classes for creating cached lookup lists that make these easier to use.
I'm not advocating going down this route. If you have to, this is how we did it.