私は、単に私がすでに持っている構造を使用しますか...
また
必須フィールドを含むデータベースを作成しますか...
それがあなたの質問の核心だと思います。
データベースから開始
私にとって、バックエンドデータベースを使用するアプリケーションを構築する場合、実体関連図は非常に重要です。http://www.sum-it.nl/cursus/dbdesign/english/index.php3で、あなたにぴったりの小さなチュートリアルを見つけましたが、学習スタイルに合ったチュートリアルを簡単に見つけることができます。重要な点は、アプリケーションが何らかの形でキャプチャできる方法で、問題のあるドメイン（アプリケーションを必要とする現実の世界）をモデル化しようとしているということです。関連するテーブルのERダイアグラムができたら、詳細を理解するのが簡単になります。SQL Server 2008（Expressエディション）用のSQL Management Studioを使用すると、いくつかの基本的なテーブルを作成し、そこにERダイアグラムを作成して、関係を生成させることができます。その後、自由に、それを達成するために使用されるSQLを調べ、それに応じて改良することができます。
個人的には、常に問題のあるドメインを調べることから始め、次にERダイアグラムを作成し、次にデータベースを作成します。データベースが問題のドメインを反映していると合理的に確信できるときに、C＃アプリケーションの構築を開始します。
C＃アプリケーションから開始
ただし、本当に重要なのは、意味のある効果的な方法で現実の世界をモデル化することです。あなたの場合、C＃で作成した構造の開始点がすでにあり、それらを使用してER図を作成するための開始点を提供できます。C＃アプリケーションを実行し、それを反映するデータベースを構築する方が簡単な場合は、それで問題ありません。おそらく、問題のドメインを効果的にキャプチャするのに役立つアプローチがすでにあるでしょう。これは、何をするにしても反復的なプロセスです。C＃コードを作成すると、基盤となるデータベース設計の問題が明らかになる可能性があり、その逆も同様です。
ダイアグラム作成-ERまたはUML？
私は、このビジネス全体が非常に複雑であるため、実際にいくつかの図が必要であると個人的に確信しています。
- データベースを視覚化するには、ER図を使用します
- C＃アプリケーションを視覚化するには、UMLクラス図を使用します
動作するアプリケーションに向かうと、これら2つの図がどのように一致し始めるか、または少なくとも他の図がかなり密接に反映されているかがわかります。どちらの場合も、（エンティティまたはクラス）オブジェクト間の関係を理解することは、データベースをクエリするときに非常に重要です。これは、テーブル間の関係を理解することが重要であるためです（特に、複雑な多対多を解決するために1対多の関係を使用する）。関係）およびクエリでテーブルを結合するためのさまざまな手法（INNERまたはOUTER結合など）C＃アプリケーションがどれほど巧妙であっても、ある時点でSQL言語の複雑さの少なくとも一部を理解する必要があります。 ER図を参照できます。
どこに保管しますか？
私が困っているのは、通常、c＃オブジェクトを辞書やリストに保存する場合、代わりにデータベースから直接取得するのでしょうか。
データベースでは、間違いなく。FamilyというAC＃クラスには、たとえば、setterメソッドが組み込まれたFamilyNameプロパティがあります。スペルミスを発見して名前を変更したい場合、setterメソッドはデータベースへの接続を開き、パラメータとして指定されたファミリ名（およびおそらくファミリID）を指定し、それに応じて基になるフィールドを更新します。データを取得するには、SELECTクエリなどを実行する必要があります。
結論
問題のあるドメインを調べ、実体関連図を作成し、その図に基づいて一連の関連テーブルを作成する方法について、いくつかのチュートリアルを実行します。そうすれば、バックエンドデータベースと通信するために構築したC＃クラスを追跡するのがはるかに簡単になると確信しています。
家族とそのメンバーの簡単なER図の例を次に示します。
まず、メンバーと家族が1つのテーブルに含まれていると思うかもしれませんが、それによって多くの重複が生じることがわかったので、それを1対多の関係で家族とメンバーのテーブルに分けます。たとえば結婚を通じて、人々は複数の家族に属することができ、多対多の関係を築く必要があります。ERダイアグラムは、そのような複雑さを解決するのに最適な場所だと思います。