如果数据被 1 个应用程序使用，那么使用数据库表而不是仅仅硬编码一个简单的数据列表的好处[关闭]

Question

一段时间以来，很多人告诉我，美国的清单州（和地区）应存储在数据库表中并缓存以供使用该信息的应用程序使用。他们给我的唯一理由是促进正常化，因为“这就是我们一直这样做的方式”。

现在，如果由于应用程序范围在国际范围内扩展（例如包括加拿大省份）而导致列表经常发生变化，我可以理解将列表抽象为数据表，该数据表也可以指示国家/地区标识符。但是，如果列表几乎被锁定并且仅在应用程序的 1 个屏幕上使用，是否值得进行查询和缓存？存储 SMALLINT 外键比存储 CHAR(2) 好得多吗？总是实用吗？

我只是在思考我在与我合作过的公司中看到的这一趋势。

Answer 1

我将它们放入数据库中有几个原因：

1. 这只是良好的标准化实践。

2. 如果我可以通过将数据放入数据库来避免这种情况，为什么还要对应用程序中的任何数据进行硬编码呢？

3. 就我个人而言，我喜欢保证独特性的舒适感。当两个表指向同一个外键时，我知道它们引用的是同一事物。当两个碰巧共享相同的两个字符代码时......好吧，那就取决于应用程序了。

4. 约束检查....很多两个字符代码都是非法的，但是数据库无法帮助您解决这个问题。非法外键输入要困难得多。

5. 速度。我没有进行基准测试，所以我可能是错的，但我敢打赌让数据库为您组合条目比您自己做要快。如果您将州代码用于其他用途（例如，获取州的非缩写名称，或维护该州的有效邮政编码列表），则联接可能比您编写的任何内容都要快。

Answer 2

如果要附加更多信息，例如国家人口或经济输出到主信息，然后一个FK使这种扩张（和随后的查询）更简单和更的可扩展

当你可以正常化 - ！为什么不

Answer 3

您可能希望选择数据库解决方案而不是硬编码解决方案的几个原因。

可扩展性原因：

• 以编程方式添加记录（尽管新状态不太可能在应用程序的生命周期内出现，但用户有时会有奇怪的需求）。这甚至可以通过专用屏幕留给应用程序的用户。如果这些值是硬编码的，您将必须提供新版本的软件。
• 将信息添加到记录中。例如，可能会要求您添加用户可编辑的人口字段。

诚信理由：

• 外键会给你完整性约束：如果您有外键，您肯定永远不会添加带有错误状态代码的记录。请注意，您可以使用代码作为键，这将避免连接问题。

选择仍然取决于应用程序的规模、用户数量和生命周期。这些数字越大，您就越应该考虑数据库解决方案。

Answer 4

有没有真正的日期使用4位数字的一年有什么好处？这似乎并不可能在COBOL这七十应用存活到2000年。

如果布什的计划将北美自由贸易联盟（NAFTA）和它的货币联盟与Amero不是最后步骤和BC，安大略etc.become状态？

Answer 5

我完全同意，这是足够不太可能的国家名单将在我们的有生之年，你可以硬编码列表中更改。

但有理由把它放在一个数据库会这样，你可以用满状态名称链接状态缩写。然后你可以使用状态缩写为唯一键，并做其加入。这将是值得的正常化。

我从来没有听说过一个令人信服的理由不使用状态缩写作为一个独特的密钥，即使它违背了“正确”的数据库设计。就像我从来没有见过归到第五水平有任何形式的性能数据库。虽然第五正常形式是一个整洁和教育锻炼。

Answer 6

如果以后要添加美国领土你刚才插入表和田田！

另外，作为艾登说，如果你想连接到这些记录的详细信息，这将是更容易建立断时，其在DB比如果硬编码

Answer 7

我说没有。如果它是一个单一的应用程序，你会维护你没有做任何事情更复杂的比状态筛选查询，你可以马上添加/硬编码的数组中删除的状态。不过，如果你做了很多复杂的连接涉及国家作为键，那么你可能会想将它们放在一个表。

Answer 8

您在数据库中保存使用外键。

Answer 9

我们可以添加51个州。