テーブルを分岐するという繰り返しの問題を止めるための戦略を探しています。たとえば、架空のユースケースとして、名前、ログイン、パスワード、およびその他のメタデータを含むユーザーのテーブルがあるとします。この特定のシナリオでは、ユーザーが IP の特定のサブセットごとにログインするように制限されているとします。したがって、1:M の関係があります。次のようなユースケースが発生するたびに、通常のワークフローには「users」テーブルと「user_ips」などのテーブルが含まれます。この場合、pk(ip_id)、fk( user_id) と user_ips 側の IP。
同様の状況で、皆さんは通常、上記のようにファンアウトしますか? ここで効果的に非正規化する機会はありますか? おそらく、CSV で区切られた方法で IP を BLOB 列に保存しますか? 皆さんが現在展開している戦略は何ですか?
非正規化の機会？常識を誤解しているかもしれません。非正規化は最適化手法です。あなたが探しに出かけるものではありません。
潜在的な関連アイテムの数が多い場合の正規化されたソリューションは、適切にインデックス付けされている場合、非正規化されたソリューションを実行しなくなると思われます。私の戦略は、データベースを正規化してから、インデックス付き結合を利用してコストを負担できるようにするビューまたはテーブルベースの関数を提供することです。パフォーマンスの要求により、非正規化された形式への移行が指示されます。
これを覚えておいてください。情報の一部への役割ベースのセキュリティアクセスを実装する必要がある場合、テーブルベースのセキュリティは、特にデータベースまたはデータ層レベルで、列ベースよりもはるかに簡単に実装できます。
フィールドに複数の IP アドレスを入力しないことを強くお勧めします。3NF を気にしないでください。これは 1NF を破ります。
Tvanfssonは、「users_ips」テーブルに何百万ものレコードが存在しない限り、FKEY にインデックスを付けると、かなり同等のパフォーマンスが得られるという点で正しいです。
さらに優れているのは、これらのテーブルを正規化したままにしておくことで、将来この情報を実際にレポートできるため、ユーザーが特定の LAN からログインできない理由について混乱している場合に、アプリ (または SQL) を作成してトラブルシューティングを行い、ユーザーを実行できることです。 IP ルックアップは非常に簡単になります。
1つのオプションは、IPアドレスをxml文字列として保存することです。これはコンマ区切りのリストよりも優れており、データベースを変更せずに必要な場合（ポートが頭に浮かぶ）、文字列に他の要素を柔軟に追加できると思います。
ただし、ほとんどの場合、正規化された方法の方が優れていると思います。
非正規化の問題と同様に、それに関連するコストを考慮する必要があります。特に、メイン テーブルに IP アドレスをリストすると、「どのユーザーを IP アドレス wxyz に関連付けることができるか?」という質問にどのように答えることができるでしょうか。完全に正規化された形式を使用すると、これは簡単で、「どの IP アドレスをユーザー pqr に関連付けることができるか?」と対称的です。非正規化形式では、質問の答えが大きく異なります。また、一般に、正しい整合性ルールが適用されることを保証することは、非正規化バージョンでははるかに困難です。
私見、それはすべて費用対効果の分析に関するものです。すべては、要件 (考えられるものを含む) と使用しているプラットフォームの機能に依存します。
たとえば、「システムに記録されているすべての一意の IP アドレスを表示する」などの要件がある場合は、今すぐ「分岐」して、IP アドレスを格納する別のテーブルを作成することをお勧めします。または、IP アドレスに特定の制約 (「特定のユーザーのすべての IP アドレスは一意でなければならない」など) が必要な場合は、別のテーブルと適切な制約を適用することで大きなメリットが得られる可能性があります。非正規化された設計と適切な XML 関連の機構を使用した場合; ただし、これらの要件に対する RelDB ベースのソリューションは、実装と保守にはるかに安価であるように思われます.)
明らかに、正規化されたソリューションを指示する要件の例はこれらだけではありません。
同時に、「ユーザーのすべての IP アドレスを表示する」や「特定の IP アドレスに関連付けられているすべてのユーザーを表示する」などの要件は、正規化されたソリューションを正当化するには不十分であると思います。
(最初のタイプの要件を求めて) より深い分析を実行するか、プロジェクトのコンテキスト (現在および将来) の理解と「直感」に頼ることができます。
この特定のケースでの私自身の「直感」は、最初のタイプの要件 (プロ正規化要件) の可能性が非常に高いということです。そのため、最初から正規化されたソリューションを使用する方がよいでしょう。ただし、このユースケースは架空のものであると述べたので、実際の状況では結論が正反対になる可能性があります。
「決して」とは言わない: 3NF が常に最良の答えであるとは限りません。
ユーザーが持つことができる属性のタイプを定義できるユーザー属性テーブルと属性タイプ テーブルを検討することをお勧めします。新しいユースケースはそれぞれ属性タイプになり、データは単純にユーザー属性テーブルに追加されます。
IP アドレスの例では、IP の属性タイプを持ち、それぞれの IP をユーザー属性テーブルに格納します。これにより、MAC アドレスなどの別のタイプを柔軟に追加できるようになり、新しいデータ タイプをサポートするために新しいテーブルを作成する必要がなくなります。新しいユースケースごとに、データを追加する必要はありません。
欠点は、この属性構造を考えると、クエリがもう少し複雑になることです。