你把字典数据放在哪里？
假设我的应用程序中有一组国家/地区。 我预计这些数据会改变，但不会经常改变。 换句话说，我不会将此集合视为操作数据（例如，我不会为 Country 提供 CRUD 操作）。
这就是说我必须将这些数据存储在某个地方。 我看到有两种方法可以做到这一点：
数据库驱动。 创建并填充国家/地区表。 提供某种 DAO 来访问它（findById() ？）。 这样，客户端代码必须知道国家/地区的 ID（也可以是名称或 ISO 代码）。 在应用程序方面，我将有一个国家/地区类。
应用程序驱动。 创建一个枚举，我可以在其中列出我的系统已知的所有国家/地区。 它也将存储在数据库中，但不同之处在于，现在客户端代码不必具有查找方法（findById、findByName 等）和硬编码 Id、名称或 ISO 代码。 它将直接引用特定国家/地区。
我倾向于第二种解决方案有几个原因。 你怎么做到这一点？
称其为“字典数据”是否正确？
附录：这里的主要问题之一是，如果我有一个像 findByName("Czechoslovakia") 这样的查找方法，那么在 1992 年之后，这将不会返回任何内容。 我不知道客户端代码将如何对其做出反应（毕竟它希望总是返回国家/地区，因为，嗯，它是字典数据）。 如果我有像 findById(ID_CZ) 这样的东西，情况会变得更糟。 找到所有这些依赖项真的很难。
如果我将 Country.Czechoslovakia 从我的枚举中删除，我将强迫自己处理对捷克斯洛伐克的任何依赖。
Let's say I have a set of Countries in my application. I expect this data to change but not very often. In other words, I do not look at this set as an operational data (I would not provide CRUD operations for Country, for example).
That said I have to store this data somewhere. I see two ways to do that:
Database driven. Create and populate a Country table. Provide some sort of DAO to access it (findById() ?). This way client code will have to know Id of a country (which also can be a name or ISO code). On the application side I will have a class Country.
Application driven. Create an Enum where I can list all the Countries known to my system. It will be stored in DB as well, but the difference would be that now client code does not have to have lookup method (findById, findByName, etc) and hardcode Id, names or ISO codes. It will reference particular country directly.
I lean towards second solution for several reasons. How do you do this?
Is this correct to call this 'dictionary data'?
Addendum: One of the main problems here is that if I have a lookup method like findByName("Czechoslovakia") then after 1992 this will return nothing. I do not know how the client code will react on it (after all it sorta expects always get the Country back, because, well, it is a dictionary data). It gets even worse if I have something like findById(ID_CZ). It will be really hard to find all these dependencies.
If I will remove Country.Czechoslovakia from my enum, I will force myself to take care of any dependency on Czechoslovakia.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在我开发的一些应用程序中，数据库中有一个包含所有此类数据的“枚举”表。 它仅由两列组成：EnumName 和 Value，并且将按如下方式填充：
然后在应用程序执行开始时读入并缓存。 优点是我们没有为每个不同的枚举类型使用数十个数据库表； 如果我们需要更改数据，我们不必重新编译任何内容。
这可以轻松扩展以包含额外的列，例如指定默认排序顺序或替代 ID。
In some applications I've worked on there has been a single 'Enum' table in the database that contained all of this type of data. It simply consisted of two columns: EnumName and Value, and would be populated like this:
This was then read in and cached at the beginning of the application execution. The advantages being that we weren't using dozens of database tables for each distinct enumeration type; and we didn't have to recompile anything if we needed to alter the data.
This could easily be extended to include extra columns, e.g. to specify a default sort order or alternative IDs.
这对你没有帮助，但这取决于...
-你打算对这些国家做什么？
您是否会将它们存储在数据库的其他表中/如果您添加新的国家/地区，现有数据会发生什么情况/其他应用程序是否会访问这些数据？
-您打算将国家名称翻译成多种语言吗？
-您的应用程序的业务逻辑是否取决于所选的国家/地区？
-您需要乡村课程吗？
等等...
如果没有更多信息，我将从几个国家/地区的枚举开始，然后根据我的需要进行重构...
This won't help you, but it depends...
-What are you going to do with those countries ?
Will you store them in other tables in the DB / what will happen with existing data if you add new countries / will other applications access to those datas ?
-Are you going to translate the contry names in several languages ?
-Will the business logic of your application depend on the choosen country ?
-Do you need a Country class ?
etc...
Without more informations I would start with an Enum with a few countries and refactor depending on my needs...
如果它不会经常更改，并且您有能力关闭应用程序以应用更新，我会将其放入 Java 枚举中并为
findById()、编写我自己的方法findByName()等等。优点：
缺点：
如果将数据放在自己的 jar 文件中，则更新就像更新 jar 并重新启动应用程序一样简单。
消费者可以通过存储枚举本身的值，或者通过引用不太可能因国家/地区而改变的 ISO 代码来消除硬编码问题......
如果您担心保持此枚举与数据库，编写一个集成测试来准确检查并定期运行它（例如：在 CI 机器上）。
If it's not going to change very often and you can afford to bring the application down to apply updates, I'd place it in a Java enumeration and write my own methods for
findById(),findByName()and so on.Advantages:
Disadvantages:
If you place the data in its own jarfile, updating is as simple as updating the jar and restarting the application.
The hardcoding concern can be made to go away either by consumers storing a value of the enumeration itself, or by referencing the ISO code which is unlikely to change for countries...
If you're worried about keeping this enumeration "in synch" with the database, write an integration test that checks exactly that and run it regularly (eg: on your CI machine).
就我个人而言，我一直选择数据库方法，主要是因为我已经在数据库中存储了其他信息，因此编写另一个 DAO 很容易。
但另一种方法可能是将其存储在 jar 中的属性文件中？ 我从来没有在 Java 中这样做过，但它似乎在 iPhone 开发中很常见（我目前正在学习）。
Personally, I've always gone for the database approach, mostly because I'm already storing other information in the database so writing another DAO is easy.
But another approach might be to store it in a properties file in the jar? I've never done it that way in Java, but it seems to be common in iPhone development (something I'm currently learning).
我可能会在我的 jar 中嵌入一个文本文件。 我会在启动时（或第一次使用时）将其加载到内存中。此时：
编辑：好的，如果您需要从代码引用特定国家/地区数据，则可以：
最终，这是一个平衡利弊的情况 - 如果上述优点与您无关（例如，手头上总是有编码员，并且部署不是问题），那么枚举就有意义了。
I'd probably have a text file embedded into my jar. I'd load it into memory on start-up (or on first use.) At that point:
EDIT: Okay, if you need to refer to the particular country data from code, then either:
Ultimately it's a case of balancing pros and cons - if the advantages above aren't relevant for you (e.g. there'll always be a coder on hand, and deployment isn't an issue) then an enum makes sense.
使用数据库表的优点之一是您可以放入 外键 约束。这样您的引用完整性将始终完好无损。 无需按照 DanVinton 建议运行集成测试枚举，它永远不会失去同步。
我也不会尝试将通用枚举表制作为 saw-lau 建议，主要是因为您失去了干净的外键约束，这是将它们放在数据库中的主要优点（可能很好地将它们粘贴在文本文件中）。 数据库擅长处理大量表。 如果您想以某种方式区分表名，请在表名前加上“ENUM_”前缀。
应用程序始终可以在启动时或由重新加载事件触发时将它们加载到地图中。
编辑：从评论中，“当然，我会在数据库中使用外键约束。但是可以在应用程序端使用或不使用枚举来完成”
啊，我在阅读第二个项目符号时错过了这一点你的问题中的要点。 不过我还是说最好将它们加载到Map中，主要基于DRY。 否则，当任何维护它的人要添加一个新的国家/地区时，他们肯定会在一个地方进行更新，而不是在另一个地方进行更新，并且会摸不着头脑，直到他们发现需要在两个不同的地方进行更新。 过早优化的案例。 恕我直言，性能优势将是最小的，代价是代码的可维护性较差。
One of the advantages of using a database table is you can put foreign key constraints in. That way your referential integrity will always be intact. No need to run integration tests as DanVinton suggested for enums, it will never get out of sync.
I also wouldn't try making a general enum table as saw-lau suggested, mainly because you lose clean foreign key constraints, which is the main advantage of having them in the DB in the first place (might was well stick them in a text file). Databases are good at handling lots of tables. Prefix the table names with "ENUM_" if you want to distinguish them in some fashion.
The app can always load them into a Map as start-up time or when triggered by a reload event.
EDIT: From comments, "Of course I will use foreign key constraints in my DB. But it can be done with or without using enums on app side"
Ah, I missed that bit while reading the second bullet point in your question. However I still say it is better to load them into a Map, mainly based on DRY. Otherwise, when whoever has to maintain it comes to add a new country, they're surely going to update in one place but not the other, and be scratching their heads until they figure out that they needed to update it in two different places. A case of premature optimisation. The performance benefit would be minimal, at the cost of less maintainable code, IMHO.
我会开始做最简单的事情 - 枚举。 当国家/地区的更改几乎与我的代码一样频繁时，我会将表设为外部，以便可以在不重建的情况下进行更新。 但请注意，当您将其设为外部时，您会添加一整套 UI、测试和文档蠕虫。
I'd start off doing the easiest thing possible - an enum. When it comes to the point that countries change almost as frequently as my code, then I'd make the table external so that it can be updated without a rebuild. But note when you make it external you add a whole can of UI, testing and documentation worms.