Java 在数据库中存储枚举

我有一个数据库，用于招聘大学作业的网络申请。 我在数据库中有很多枚举值，比如城市名称、广告类别或语言列表。 数据库的一部分：

我的目标是防止用户通过输入发送并创建一些无效数据，例如，我们希望像“LA”、“L.A”和“Los Angeles”这样的值由

city

表中的一个ID表示。 我还认为将其存储在数据库表中是个好主意，因为对于给定的一组值，我可以将它们视为标记，这将改进搜索过程。此外，扩展这些值也很容易，例如向列表中添加新语言

不幸的是，教授说这不是一个最佳解决方案，所以我的问题是，在上述情况下，存储易于扩展的枚举值列表的最佳方法是什么

---

我正在使用PostgreSQL，应用程序将使用运行在Glassfish上的Java EE构建。

虽然从纯体系结构的角度来看这似乎是有意义的，但我将其归类为数据库设计反模式。从根本上说，这是对枚举的不当使用。您的明显目标是通过强制用户从正确值列表中进行选择来防止用户输入错误的值。虽然你的目标很高尚，但最终还是有缺陷的，原因如下：

维护地球上每个城市的准确列表超出了DBA的范围。城市出现的规律性比你想象的要大得多，而且没有一个简单而全面的列表可以供你复制

由于您无法维护一个全面的列表，您和/或您的应用程序将需要一种机制来输入新值。这将挫败你保证正确价值观的目标

这是对数据库模式的过度规范化。您真的不想为了确定单个信息字段的值而进行复杂的联接

---

替代的解决方案是维护一个已知好名字的列表，并使用自动补全来建议已知的正确值，但允许用户输入一个不在列表中的新值。不要将城市存储为枚举，而是直接将其与其他逻辑分组数据一起存储。

虽然从纯粹的架构角度来看这似乎是有意义的，但我会将其归类为数据库设计反模式。从根本上说，这是对枚举的不当使用。您的明显目标是通过强制用户从正确值列表中进行选择来防止用户输入错误的值。虽然你的目标很高尚，但最终还是有缺陷的，原因如下：

维护地球上每个城市的准确列表超出了DBA的范围。城市出现的规律性比你想象的要大得多，而且没有一个简单而全面的列表可以供你复制

由于您无法维护一个全面的列表，您和/或您的应用程序将需要一种机制来输入新值。这将挫败你保证正确价值观的目标

这是对数据库模式的过度规范化。您真的不想为了确定单个信息字段的值而进行复杂的联接

---

替代的解决方案是维护一个已知好名字的列表，并使用自动补全来建议已知的正确值，但允许用户输入一个不在列表中的新值。不要将城市存储为枚举，而是直接将其与其他逻辑分组数据一起存储。

我觉得这很好。你应该问你的老师为什么他认为这不是一个好的解决办法。我有点困惑。。。您是打算创建一个Java枚举来表示数据库中可能的值，还是仅仅创建一个具有有限选项的数据库，用户可以从中进行选择？我认为在数据库中存储枚举没有任何问题。但是你应该在你的应用程序中使用一些缓存工具，比如ehcache。城市不是经常修改的，所以你可以在内存中缓存值，并且你不必为每个请求都点击数据库。@marcellorvalle最初我想将值存储在数据库中，但现在我正在寻找不同/更好的解决方案（如果存在）。这对我来说似乎很好。你应该问你的老师为什么他认为这不是一个好的解决办法。我有点困惑。。。您是打算创建一个Java枚举来表示数据库中可能的值，还是仅仅创建一个具有有限选项的数据库，用户可以从中进行选择？我认为在数据库中存储枚举没有任何问题。但是你应该在你的应用程序中使用一些缓存工具，比如ehcache。城市不经常被修改，因此您可以在内存中缓存值，并且您不必为每个请求都点击数据库。@marcellorvalle最初我想将值存储在数据库中，但现在我正在寻找不同/更好的解决方案（如果存在）。如果我想拥有像本例中这样的小城市列表，该怎么办？我将有大约50个我国最大的城市可供选择，而且该应用程序将允许用户输入自己的城市名称，以及适用于大学的相同规则。那么，不可变的企业列表和广告类别又如何呢？使用“已知良好”城市列表作为自动完成用户界面就可以了，但不建议将数据存储为枚举。使用枚举仍然会产生过度规范化的问题。因此，在这种情况下，例如表

城市
和
雇主
在ERD中没有关联？而
employee
有一列
city
存储字符串值，而不是
city\u id
？我建议删除当前使用的city表，并用存储实际城市的city列替换对city\u id的所有引用。如果你想有一个城市名称的查找表