如何处理不是真正枚举的枚举，因为它们可以更改？
我正在为课程开发一个网络应用程序。它基本上是一个项目管理系统，类似于 Bugzilla 的淡化版本，但专门针对学术环境量身定制。要求之一是对于许多设置（例如可以是硕士项目、博士论文等的项目类型），可能值的列表是可配置的。因此，将会有一个配置或设置页面，您可以在其中更改每个列表中的值，但随后在应用程序的其余部分（例如创建项目或任务时）列表中的值将是唯一可供选择的选项。此外，如果您更改其中一个值（例如从硕士论文到硕士论文），使用该值的所有记录也应该更改。因此，所有标记为硕士论文的项目现在都将标记为硕士论文。
我使用 HSQLDB 来存储数据，并且该应用程序全部用 Java（JDBC、JavaServlets、JSP）编写。
我很难从设计的角度弄清楚如何处理这个要求。首先，如何将这些列表存储在数据库中？每个列表都是它自己的表吗？让每个列表成为一个表中的一列似乎是错误的（这不会违反规范化规则吗？）。我对数据库设计不是很熟悉，但是谷歌搜索还没有找到一个好的解决方案。
其次，我如何在代码中处理这些列表？我一直在考虑在关联的类中使用静态变量（某种集合），因为这些设置是全局的，而不是特定于某个用户或项目的。但这通常不被认为是好的设计。
任何建议将不胜感激。我想要正确的设计不仅因为这是软件工程课程所以设计很重要，而且因为我最终可能会将这个项目扩展为硕士项目。
I'm working on a web app for a class. It's basically a project management system, similar to a watered down version of Bugzilla, but specifically tailored for an academic environment. One of the requirements is that for a number of settings (such as project type which could be master's project, PhD thesis, etc.) the lists of possible values be configurable. So there would be a configuration or settings page where you could change the values in each list, but then in the rest of the app (like when creating a project or task) the values in the list will be the only options to choose from. Also if you change one of the values (say from master's paper to master's thesis) all the records which use that value should have it changed, too. So all projects marked as master's paper would now be marked as master's thesis.
I'm using an HSQLDB to store data and the app is written all in Java (JDBC, JavaServlets, JSP).
I'm having a hard time figuring out how to deal with this requirement from a design perspective. First, how do I store these lists in the database? Would each list be its own table? Having each list be a column in one table seems wrong (wouldn't that violate normalization rules?). I'm not super familiar with database design, but googling hasn't revealed a good solution to this.
Second, how do I treat these lists in my code? I've been thinking of using static variables (Collections of some sort) in the associated classes, because these settings are meant to be global, not specific to one user or project. That's generally not considered good design though.
Any recommendations would be greatly appreciated. I want to get the design correct not only because this is a software engineering class so design is important, but also because I may end up expanding this project into a master's project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是标准标准化。
创建一个列表表
，然后根据需要将其关联到另一个表
用于设置 my_other_table 值的 UI 查询 mylist 以获取应进入组合框或您选择的任何 UI 组件的值。
this is standard normalization.
create a list table
then associate it to the other table as appropriate
the UI for setting values for my_other_table queries to mylist for the values that should go into the combo box or whatever UI component you choose.
每个“枚举”应该存储在它自己的表中，以便您可以拥有该表的外键。
您可以将每个“枚举”的所有可能值存储在缓存中，以避免每次需要选项列表时都访问数据库，但请注意不要建议陈旧的数据。由于条目的数量应该非常小，因此在遇到真正的问题之前我不会太关心性能。
Each "enum" should be stored in its own table, so that you can have foreign keys to this table.
You could store all the possible values of each "enum" in a cache, to avoid going to the database each time you need the list of options, but be careful not to propose stale data. Since the number of entries should be very small, I wouldn't care much about performance until you have a real problem.
在我的公司，我们有表 Dictionary（类、字段、值、描述） - 对于每个类和字段，我们有与允许的值一样多的行，并且它工作得很好。
In my company we have table Dictionary(class, field, value, description) - and for each class and field we have as many rows, as there are allowed values, and it works quite well.