Accountプロジェクトのデータベースにテーブルを作成しています。各アカウントには多くのプロパティがあります:
それらのほとんどは nullable です。私の質問は、データベースでこれをどのように設計すればよいですか?
これらすべてのプロパティを持つ 1 つのテーブルにする必要がありますか? AccountSetまたは、 、、 のような 2 つのテーブルを作成してAccountInfoSet、「高度な」ユーザーの設定をすべて保存する必要があるでしょうか。最後になりましたが、これが 2 つのテーブルである場合、それらのテーブル間にどのような関係が必要でしょうか?
これがリレーショナルデータベースの場合、これらのプロパティをアカウントテーブルのフィールドとして保存することは絶対にありません。いくつかの理由：
アプリケーションが本番環境に移行すると（またはすでに存在している場合）、スキーマの保守は悪夢になります。あなたは絶対にもっと多くのプロパティを追加するでしょう、そして生産でそのテーブルに絶えず触れなければならないことは苦痛です。
ほとんどの場合、孤立したフィールドになってしまいます。これは、プロパティを導入して使用を停止する場所を何度も見たことがありますが、スキーマに組み込まれているため、怖くて削除できない可能性があります。
理想的には、テーブルにそのようなスパースデータ（多くのnullを持つ多くのフィールド）が含まれないようにする必要があります。
私の提案は、あなたがすでに考えていることを実行することであり、それはアカウントのプロパティテーブルを導入することです。あなたはそれをAccountInfoSetと呼んだ。
テーブルは次のようになります。
AccountId int、プロパティnvarchar（50）、値nvarchar（50）
（もちろん、必要に応じてデータ型とサイズを設定します。）
次に、AccountInfoSetテーブルに参加し、「高度な」プロパティをピボットします。クエリを使用して行を列に変換します。
.NETでは、1回の呼び出しで2つのクエリを返し、DataSetオブジェクトのテーブルを確認するストアドプロシージャを作成することもできます。
または、2つの別々の呼び出しを行うこともできます。1つはアカウント用、もう1つはプロパティ用です。
情報を取得する方法はたくさんありますが、リレーショナルデータベースを使用している場合は、アカウントにフィールドを追加するだけではないことを確認してください。