しばらくの間、米国の州 (および準州) のリストをデータベース テーブルに格納し、その情報を使用するアプリケーション用にキャッシュする必要があると多くの人から言われてきました。彼らが私にこれを与えた唯一の理由は、正規化を促進するためであり、「それが私たちが常に行ってきた方法である」ためです.
アプリケーションの範囲が国際的に拡大するためにリストが頻繁に変更される場合 (たとえば、カナダの州を含めるなど)、国識別子も示すデータテーブルにリストを抽象化することは理解できます。ただし、リストがほとんどロックされており、アプリケーションの 1 つの画面でしか使用されていない場合、クエリとキャッシュを実行する価値はありますか? SMALLINT 外部キーを保存することの違いは、CHAR(2) よりもはるかに優れていますか? それは常に実用的ですか？
私が一緒に働いた会社で見たこの傾向について考えていました。
いくつかの理由で、私はそれらをデータベースに入れました：
これは、正規化の良い方法です。
データベースにデータを配置することでデータを回避できるのに、なぜアプリケーションにデータをハードコーディングする必要があるのですか？
個人的に、私は保証された独自性のプロパティの快適さが好きです。2つのテーブルが同じ外部キーを指している場合、それらが同じものを参照していることがわかります。2つがたまたま同じ2つの文字コードを共有する場合...まあ、それはアプリケーション次第です。
制約チェック....2つの文字コードの多くは違法ですが、データベースはそれを支援することはできません。違法な外部キー入力を行うことは非常に困難です。
スピード。私はベンチマークを行っていないので、間違っているかもしれませんが、データベースにエントリを結合させる方が、自分で行うよりも速いと思います。状態コードを他の目的で使用している場合（たとえば、状態の省略されていない名前を取得するため、またはその状態の有効な郵便番号のリストを維持するため）、結合はおそらくあなたが書くものよりも高速です。
州の人口や経済産出などの情報を一次情報に追加したい場合は、FK を使用すると、この展開 (およびその後のクエリ) がより簡単になり、拡張性が高まります。
正規化できる場合 -- ノーマライズしないでください。
ハードコードされたソリューションよりもデータベースソリューションを選択したい理由がいくつかあります。
拡張性の理由：
完全性の理由：
それでも、選択は、アプリケーションのサイズ、ユーザー数、および寿命によって異なります。これらの数値が大きいほど、データベースソリューションを検討する必要があります。
日付の年に 4 桁を使用する利点は本当にありますか? この 70 年代の COBOL アプリが 2000 年まで存続する可能性は低いように思われました。
北米自由貿易連合 (NAFTA)に対するブッシュの計画と、アメロとの通貨統合が最後のステップではなく、BC、オンタリオなどが州になったらどうなるでしょうか?
リストをハードコーディングできるほど、私たちの生涯で状態リストが変更される可能性は十分に低いことに完全に同意します。
しかし、それをデータベースに入れる理由は、州の省略形を完全な州名にリンクできるようにするためです。次に、州の略語を一意のキーとして使用して、結合を行うことができます。これは価値のある正規化です。
「適切な」データベース設計に反するとしても、州の省略形を一意のキーとして使用しないという説得力のある理由を聞いたことがありません。5 番目のレベルに正規化されたデータベースで、何らかのパフォーマンスが得られたのを見たことがないのと同じように。第 5 正規形はきちんとした教育的な演習ですが。
51番目の州を追加する可能性があります。
後で米国領土を追加したい場合は、テーブルに挿入するだけです。
また、Aidenが言ったように、それらのレコードに添付されたより多くの情報が必要な場合は、ハードコードされている場合よりもDBにある場合の方が簡単に構築できます
データベースで外部キーを使用できます。