使用Java中的枚举作为小型数据库的替代方法

我有一个使用类“Country”的java应用程序.业务逻辑将世界上每个国家/地区与：一个iso代码.电话国家/地区呼叫代码适用于该国家/地区的TZ数据库时区ID列表通常,这是数据非常适合数据库.但是,鉴于这个数据非常稳定...

我有一个使用类“Country”的java应用程序.业务逻辑将世界上每个国家/地区与：

>一个iso代码.
>电话国家/地区呼叫代码
>适用于该国家/地区的TZ数据库时区ID列表

通常,这是数据非常适合数据库.但是,鉴于这个数据非常稳定(当然,它会不时改变,但通常不会用于对这些记录执行创建/更新/删除操作),我在考虑将信息放入类似的枚举中这个：

public enum Country
{

   US(1,new String[]{"America\New York","America\California",...}),

   ...

   NL(31, new String[]{"Europe\Amsterdam"});

    ...

    public Country(int telephoneCode, String[] timezoneIds)
    {
       ...
    }
}

这种方法的可能优势：

>数据可以直接从java源代码访问,因此进行数据库查询没有延迟.
>无需在某处设置和维护数据库文件(这对我来说很重要,因为我还不熟悉JDBC)

缺点可能是：

>数据在源代码中“隐藏”,如果政治发生变化,则不会自动更新.
>如果枚举更改,则必须重新分发代码. (见this question.)
>与数据库查询相比,获取特定信息的“大”枚举(超过200个可能的值)的性能有多好？

我想问一下粗体问题(缺点#3),但欢迎任何有关大局的评论.

我知道java中的Locale类,它可以用来获取java系统中已知的所有可能国家的列表.遗憾的是,无法提供电话和时区信息.我的意图是将这些数据合并为一个枚举.这种做法是否被视为合理的替代方案或黑客反模式？

解决方法:

到目前为止,我只能同意这些意见.国家列表可能会发生变化,但它总是小到足以将整个列表保留在内存中.如果仅查询一次然后缓存,则性能上的任何差异都无关紧要.

这可能取决于谁在使用该软件(个人用途或大公司)但我会说这里最大的担忧是#2,而不是#3.在代码与数据库中,应根据谁可能必须稍后更改值来决定.您是否真的需要开发人员更改值,重新编译所有内容并推出新版本或软件补丁？只更新文本文件或数据库将更容易.

如果它是一个个人项目,那么论证可能对您无关紧要,但即便如此,文本文件(例如CSV格式)可能比代码更容易维护.我仍然建议使用一个简单的数据库 – 只是为了学习体验.您不需要设置像MySQL这样庞大的数据库系统.您可以使用小型嵌入式数据库,如h2或Apache Derby.

仅供参考国家代码和名称的更改频率：

ISO 3611-1(定义现有国家的语言和国家代码)has been changed 17 times in the years 2007-2014.这大约是每年2.4次.