一段时间以来，许多人告诉我，美国各州（和地区）的列表应该存储在数据库表中，并为使用该信息的应用程序缓存。他们给我的唯一原因是促进正常化，因为“这是我们一直这样做的方式”。
现在，如果由于应用程序的范围在国际范围内扩大（比如说包括加拿大各省）而经常更改列表，我可以理解将列表抽象为一个数据表，该数据表也将指示国家标识符。但是，如果列表几乎被锁定并且仅在应用程序的 1 个屏幕上使用，是否值得进行查询和缓存？存储 SMALLINT 外键是否比 CHAR(2) 好得多？它总是实用的吗？
只是在思考我在与我合作过的公司中看到的这种趋势。
我把它们放在数据库中，有几个原因：
这只是一个很好的规范化做法。
如果我可以通过将数据放入数据库来避免这种情况，为什么还要对应用程序中的任何数据进行硬编码？
就个人而言，我喜欢保证独特性属性的舒适性。当两个表指向同一个外键时，我知道它们引用的是同一个东西。当两个碰巧共享相同的两个字符代码时……好吧，这取决于应用程序。
约束检查....很多两个字符代码是非法的，但数据库将无法帮助您。非法外键输入要困难得多。
速度。我没有进行基准测试，所以我可能是错的，但我敢打赌让数据库为你组合条目比你自己做的要快。如果您将州代码用于其他任何事情（例如，获取州的非缩写名称，或维护该州的有效邮政编码列表），则连接可能比您编写的任何内容都快。
如果您想将更多信息（例如州人口或经济产出）附加到主要信息中，那么 FK 会使这种扩展（以及后续查询）更简单、更可扩展
什么时候可以正常化——为什么不呢！
您可能希望选择数据库解决方案而不是硬编码解决方案的几个原因。
可扩展性原因：
诚信理由：
选择仍然取决于应用程序的大小、用户数量和生命周期。这些数字越大，您就越应该考虑数据库解决方案。
在日期中使用 4 位数字真的有好处吗？在这个七十年代的 COBOL 应用程序中，它似乎不太可能存活到 2000 年。
如果布什对北美自由贸易联盟 (NAFTA)的计划以及与 Amero 的货币联盟不是最后一步，而 BC、安大略等成为州会怎样？
我完全同意，状态列表不太可能在我们的有生之年发生变化，以至于您可以对列表进行硬编码。
但是将其放入数据库的原因是您可以将州缩写与州全名联系起来。然后您可以使用状态缩写作为唯一键并对其进行连接。这将是值得标准化的。
我从来没有听说过不使用州缩写作为唯一键的令人信服的理由，即使它违背了“正确的”数据库设计。就像我从未见过标准化到第五级的数据库具有任何性能一样。虽然第五范式是一种简洁而有教育意义的练习。
我们可能会添加第 51 个状态。
如果稍后您想添加美国领土，您只需将其插入表格和 tada！
同样，正如 Aiden 所说，如果您想要将更多信息附加到这些记录中，那么在数据库中构建它会比硬编码时更容易构建
我拒绝。如果它是您将要维护的单个应用程序，并且您没有做任何比按状态过滤查询更复杂的事情，那么您可以尽快从硬编码数组中添加/删除状态。但是，如果您正在执行许多涉及状态作为键的复杂连接，那么您可能希望将它们放在一个表中。
您可以在数据库中使用外键。