《美国新闻与世界报道》(U.S. News & World Report)网站27日以“‘尼德兰’(Netherlands)不想让你再叫它‘荷兰’(Holland)”为题报道称，自2020年1月起，“荷兰”这一名称将被停用。
作为一个旅游爱好者，第一个想到的是：以后买机票去"荷兰"要找"尼德兰"了。
作为一个教育从业者，第一个想到的是：以后所有需要回答"荷兰"的题都要写"尼德兰"了。
作为一个资深程序员，第一个想到的是：我的程序还能正常运行吗？用户填写“尼德兰”是否会报错？查询的结果中是否还是有“荷兰”？
经过深思熟虑，我得出结论：我的程序可以正常运行。因为我的程序里面“荷兰”使用NL表示，只是一个Code。感谢Code Name的设计，让我在荷兰改名的时候可以安心回家。
不过这个让我想到了另一个东西BU:Business Unit，这个系统内有三个BU：PCG、DCG、MBG。系统在处理BU信息的时候直接将PCG写到了数据库中。我不担心万一哪天PCG变成PCSD怎么办，因为——已经发生了(!_!)。现在每个特性都会出现这样的问题：
-
用户选择PCSD查询条件，结果查不到结果。
-
用户下载了一堆文件里面出现了PCG，而不是想要的PCSD。
-
用户上传了一个PCSD的文件，结果查不到PCSD的数据。
整个项目深陷BU的问题，不能自拔，每个交付的特性，不在BU上出两个问题都不正常。
我深刻的体会到：无论业务看起来多么简单，数据量多么少，一定要分析一下——这个会变吗？会变一定给它一个Code。
有人可能会想：下载的时候用户可不想看Code，为了下载方便，我把Name和Code一起存起来。
这个嘛，让我们从长计议。先请用户回答一个问题：您看历史的时候到底想看到什么？类似发往荷兰的快递，2019-12-01收货，2020-01-01查看这个快递的时候，到底应该看见“荷兰”还是“尼德兰”？
-
如果用户的答案是“尼德兰”，咱们还是不要存Name了，毕竟我们使用Code就是为了隔离变化，如果我们把Name也存起来 ，岂不又回到了最初。而且，增加更新Name的功能也不简单，执行更新过程还需要时间。
除了Code的Name不建议存起来，还有一些关系信息也不建议存起来，类似国家所属的地区。说到这里，我一下子想到了很久很久以前，项目上的人都以为一个国家所属的区域不会变，然后为了搜索方便，我们把国家所属的区域编号也存了起来。就是怎么巧，两年后，欧洲一些国家所属的子区域调整了。开始用户反映数据不准确，后来我们发现是国家所属区域变化了，我们花了一周时间更新完所有历史数据。用户表示对我们的反映速度不满意。
-
如果用户的答案是“荷兰”，那我们就要考虑一下，这个是一个快照吧？是否应该给“尼德兰”一个新的Code更好呢？这个时候“尼德兰”和“荷兰”可能根本就不是一个东西。
假如“荷兰”改名“尼德兰”的原因是：一小撮有组织有预谋的不法分子，在某某广场，高呼XXXXX，并最终夺得了政权。虽然国土还是那些国土，但是新政权可不承担原来政府的承诺，类似旧政府为了镇压不法分子在国际上的借债，新政府肯定不认。作为一个国际借款公司，必须给“尼德兰”一个新的Code。当然如果是一个物流系统，还是采用方案1比较合适。
总结下来就是：
-
一定要给可变内容一个Code。麻烦一小步，省事一大步。
-
不要轻易采用冗余存储方案。
-
如果冗余存储要提供更新机制。