ユーティリティによって実行されている変換にカスタム設定をアップロードするユーザーがいるシナリオがあります。ですから、私たちが直面している問題は
これらのカスタムマッピングを、UIDまたはおそらくGUIDの追加の列を持つ1つのテーブルに保持する必要があります。
また
登録するすべてのユーザーに対してその場でテーブルを作成し、カスタムマッピング用に個別のテーブルを提供する必要がありますか？
カスタムマッピング用に1つの列と1つのテーブルだけを使用する傾向がありますが、その1つの列の冗長データはパフォーマンスに影響しますか？一方、ロジックは、テーブルを正規化し、個別のテーブルを持つように指示します。私は何をすべきかについてかなり混乱しています。
一般的な方法は、ユーザーIDを持つ単一のテーブルを使用することです。一般的に再利用される設定がある場合は、代わりにこれらを別のテーブルにリファクタリングして一度に参照することができますが、それはあなた次第です。
ユーザーごとに1つのテーブルを作成するのはなぜ悪い考えですか？ええと、100万人のユーザーがいる場合、データベースに100万個のテーブルが必要になるとは思いません。このようにすることで、クエリがせいぜい扱いにくくなり、多くの場合、本来よりも遅くなり、動的に生成およびEXEC編集されることが保証されます。通常、最後の手段であり、必ずしも安全ではありません。
私は、元の開発者がクライアントごとに1つのテーブルを使用することを選択したシステムを継承しました。現在、システムを書き直しています！開発者の観点からすると、動的SQLとループが絡み合って混乱することになります。DBAは、毎朝まったく異なるデータベースにウェイクアップし、パフォーマンスの調整と保守が不可能になるため、満足できません。
ユーザーテーブルに追加のBLOBまたはXML列を作成して、設定を保存することができます。これはプロパティバッグアプローチと呼ばれますが、多くの場合クエリのパフォーマンスを妨げるため、これもお勧めしません。
このシナリオでの最善のアプローチは、正規化の問題を解決することです。PK/FK関係でusersテーブルに結合されたプロパティの個別のテーブル。GUIDの使用はお勧めしません。このGUiDは最終的にPKになる可能性があります。つまり、16バイトのクラスター化インデックスがあり、それはテーブル上のすべての非クラスター化インデックスにも引き継がれます。おそらく、Usersテーブルでこれに非クラスターインデックスを作成することもできます。また、大規模な断片化につながるのでNEW_ID()はなく、これらのGUIDを生成するという落とし穴に陥るリスクを冒す可能性があります。NEW_SEQUENTIALID()
正規化アプローチを採用していて、2つのテーブル間で結果を表形式で返すことに懸念がある場合は、PIVOT演算子を使用するだけです。