持久数据适用于枚举 [英] Persisting data suited for enums

问题描述

大多数项目都有某些数据在发布之间基本上是静态的，非常适合用作枚举，例如状态，事务类型，错误代码等。例如，我只是使用一个常见的状态枚举：

  public enum Status {
 ACTIVE（10，Active）; 
 EXPIRED（11，已过期）; 
 / *其他状态... * / 
 
 / *构造函数，getter等* / 
} 
  

我想知道别人在持久性方面关于这些数据。我看到几个选项，每个都有一些明显的优点和缺点：

• 在状态表中保持可能的状态，并保留所有缓存在整个应用程序中使用的可能的状态域对象


• 仅使用枚举，并且不保留可用状态列表，从而在我和我的DBA之间创建数据一致性圣战。 li>
  
• 在代码中保持状态并维护枚举，但不要将它们绑在一起，创建重复的数据

我的偏好是第二个选项，尽管我的DBA声称我们的最终用户可能希望访问原始数据来生成报告，而不坚持状态会导致不完整的数据模型（反驳：这可能是解决了文档）。

大多数人在这里使用惯例？

编辑：

在考虑了一段时间后，我真正的持久性斗争来自于处理与数据库中的状态相关联的id值。这些值在安装应用程序时将作为默认数据插入。在这一点上，他们将有其他表中可用作外键的ID。我觉得我的代码需要知道这些ID，以便我可以轻松地检索状态对象并将它们分配给其他对象。我该怎么办？我可以添加另一个字段，如代码，以查看填充，或者只是通过名称查找状态，这是icky。

解决方案

我们使用数据库中的一些显式字符串或字符值存储枚举值。然后从数据库值返回到枚举我们在枚举类上写一个静态方法来迭代并找到正确的方法。

如果你期望很多枚举值，您可以创建静态映射 HashMap< String，MyEnum> 快速翻译。

不存储实际枚举名称（在你的例子中是ACTIVE），因为这很容易被开发人员重构。

Most projects have some sort of data that are essentially static between releases and well-suited for use as an enum, like statuses, transaction types, error codes, etc. For example's sake, I'll just use a common status enum:

public enum Status {
    ACTIVE(10, "Active");
    EXPIRED(11, "Expired");
    /* other statuses... */

    /* constructors, getters, etc. */
}

I'd like to know what others do in terms of persistence regarding data like these. I see a few options, each of which have some obvious advantages and disadvantages:

• Persist the possible statuses in a status table and keep all of the possible status domain objects cached for use throughout the application
• Only use an enum and don't persist the list of available statuses, creating a data consistency holy war between me and my DBA
• Persist the statuses and maintain an enum in the code, but don't tie them together, creating duplicated data

My preference is the second option, although my DBA claims that our end users might want to access the raw data to generate reports, and not persisting the statuses would lead to an incomplete data model (counter-argument: this could be solved with documentation).

Is there a convention that most people use here? What are peoples' experiences with each and are there other alternatives?

Edit:

After thinking about it for a while, my real persistence struggle comes with handling the id values that are tied to the statuses in the database. These values would be inserted as default data when installing the application. At this point they'd have ids that are usable as foreign keys in other tables. I feel like my code needs to know about these ids so that I can easily retrieve the status objects and assign them to other objects. What do I do about this? I could add another field, like "code", to look stuff up by, or just look up statuses by name, which is icky.

解决方案

We store enum values using some explicit string or character value in the database. Then to go from database value back to enum we write a static method on the enum class to iterate and find the right one.

If you expect a lot of enum values, you could create a static mapping HashMap<String,MyEnum> to translate quickly.

Don't store the actual enum name (i.e. "ACTIVE" in your example) because that's easily refactored by developers.

这篇关于持久数据适用于枚举的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！