詳細な情報を取得している車両のようなエンティティがあるとします。撮りたい車は赤、黒、白に塗られています。フロントタイヤはブリヂストンの275/35-18、リヤタイヤは325/30-19。また、タイヤが 2 つしかない場合もあれば (これは車両の一種であるオートバイと見なされます)、18 本のタイヤがすべて異なる場合もあります。次に、エンジンのサイズのように、常に単一の値であるフィールドがいくつかあります (想像力を働かせると、複数のエンジンを搭載した車両を考えることができますが、私はこれを単純にしようとしています)。
これに対処するための現在の戦略は、複数の値を持つことができるフィールドごとにテーブルを用意することです。これにより、多数のテーブルが生成され (この要件を持つさまざまなエンティティが多数あります)、少し臭いがします。これが最善の戦略ですか?そうでない場合、何が良いでしょうか?
あなたのアプリで可能性がある場合は、を調べることをお勧めします。
リレーショナル データベースを使用している場合、あなたの提案がほぼ唯一の方法です。正規形の理論はそれについてのより多くの情報を提供します - それに関するウィキペディアの記事は非常に優れていますが、より高い正規化レベルに入るとトリッキーな理論的主題であるため、少し重くなります. ただし、例はほとんど常識です。
Vehicle テーブル、Color テーブル、TyreType テーブル (英国の綴りで申し訳ありません) があると仮定すると、関連するテーブルのペア間の結合として機能する VehicleTyre テーブルと VehicleColour テーブルを定義していると考えられます。この構造は実際には非常に健康的です。必要な情報を直接カプセル化するだけでなく、どのタイヤがどれであるか (例: 左前がブリヂストン 275/35-18) や、車のどの部分が赤く塗られているか (例: VehicleColor テーブルのパーセント フィールド）。
タイヤの数を管理できる車両タイプのエンティティをモデル化することができます。これは、システムから SELECT クエリを実行するために必要ではありませんが、おそらくユーザー インターフェイスと、テーブルに挿入するタイヤの数を把握するのに役立つでしょう。
私の会社には、まさにこれに基づいて動作するスキーマがたくさんあります。実際、オブジェクト リレーショナル フレームワークは、多対多の関係を管理するためにそれらを自動的に作成します (モデル化の方法によっては、1 対多の関係の場合もあります)。私たちのアプリのいくつかには、150 を超えるエンティティと、これらの結合テーブルが 100 を超えるものがあります。いくつかのテーブル名が煩わしいほど長いことを除けば、パフォーマンスの問題はなく、データの管理性に意味のある影響もありません。
それは、変数自体が 1 つの変数しか持たないかどうかに大きく依存します (例: すべて同じタイプの可変数のタイヤ、または可変タイプのセット数のタイヤを持つことができます)。
複数の変数 (タイヤごとに特定のタイプ、タイヤの数が可変など) が必要なように思われるので、カスタマイズしたい車の特定の領域ごとに特定のテーブルを用意するのが最善の解決策であると思います。
選択する値のセット (たとえば、2 つ、4 つ、または 6 つのウィンドウ) を持ついくつかのフィールドがある場合は、単純に列挙型を使用するか、ユーザー定義ドメインを使用して新しいフィールド タイプを定義できます (使用する DBMS によって異なります)。使用しています）。
SQL Server を使用している場合は、 XML データ型を保存することを恐れないでください。これにより、このようなことがはるかに簡単になることがわかりました。
あなたの現在の戦略は正しいものです。非常に多くの種類のデータを追跡しているため、多数のテーブルが必要になります。それがまさにその通りです。DBMS は不平を言っていますか?
Star Schemaについて説明しています。あなたのようなケースではかなり標準的な慣行だと思います
編集：実際には、スキーマはスタースキーマからわずかに変更されています。各ディメンションテーブルのファクトテーブルの主キーを使用して結合するため、複数のペイントカラーなどを使用できます。いずれにしても、対処するのは良い方法だと思いますあなたのエンティティと。さらに一歩進んでディメンション テーブルを正規化すると、Snowflake Schemaが作成されます。
Hierarchical Modelと呼ばれるものを見ているようです。
それとも、(attr, value) ペアの単純なリストで十分でしょうか?