gps システムに関する mysql データベースがあります。約70テーブルあります。
テーブルの 1 つは vehicle と呼ばれ、車両の ID を含む列が 1 つだけあり、それが主キーです。
残りのテーブルには、すべて外部キーであるvehicleIdという列が含まれています。
非常に多くの外部キーが 1 つのテーブルだけを指しているのが普通なのか、心配になり始めました。
実際、これは私の質問です。1 つの主キーのみを指す 70 個の外部キーを持つことは正しいですか?
PS リレーションには 1 対 1 のものもあれば、1 対多のものもあります。
引用した問題は、必ずしも問題があることを意味するわけではありませんが、これが良い設計であることを意味するわけではありません。
代替手段は何ですか？その車両情報を 70 のテーブルに複製しますか? それは私には良い考えのようには聞こえません。
ID のみを含む 1 つの列を持つ車両テーブルがわかりません。必要な車両に関する意味のある属性はありませんか? ヴィン？作る？モデル？年？ガレージの住所？私はこの音が好きではありません。これだけに基づいて、あなたのデザインの残りの部分に疑問を呈します。
70 テーブルは多くありません。
あなたの問題は正確には何ですか？過剰な JOIN が原因でパフォーマンスが問題になっていることに気付きましたか? JOIN 内の 7 つ以下のテーブルは、通常の経験則です。
すべてのテーブルがこのように結合されていることを心配します。結合しすぎたオブジェクト モデルと同じ問題があります。なぜこの場所にたどり着いたのかを説明するには、問題について十分な詳細を提供していませんが、自然に関連するテーブルのクラスターを持つより良い設計を期待しています. みんなと話していると、まるで 1 つの大きなテーブルのように感じます。全然ダメ。
何よりもまず、何らかのリレーショナル データベース管理システム (おそらく SQL システム) を使用していると想定しています。
「現実世界」の関係が正しい場合、つまり、70 のテーブルのそれぞれの各行が 1 台の車両の情報に関するデータを本当に保持している場合、これを行うこと自体には何の問題もありませんが、通常はより多くの情報が見つかると予想されますが、 「vehicles」テーブルの単一の主キー値よりも。
純粋なデータベースの正規化の観点から、1 対 1 のテーブル マッピングが関係している場合、各テーブルの列を「vehicles」テーブルに移動できると主張できます。しかし、他の 1 対 1 のテーブルに膨大な数の列がある場合、テーブルを読み取ろうとしている人にとっては扱いにくいように思えます (誰かがテーブルを直接見ることに興味があると仮定すると...とにかく、これはすべてアプリケーションのフロントエンドによって抽象化されるか、単純なクエリを使用して多数の列を持つ単一のテーブルを選択的に調べることになります)。
繰り返しますが、データベースの一部を選択的に非正規化することには、パフォーマンス上の理由がある場合があります。
それはすべて、あなたが何を達成しようとしているかにかかっています。正規化と非正規化の理論を十分に理解することは、おそらく開始するのに適した場所です。
私は通常、RDBMS の場合、特に理由がない限り、デフォルトで正規化するというアプローチを取ります。そして、パフォーマンスを改善するためのオプションとして非正規化を検討する前に、適切にインデックスを作成し、クエリを構造化することを検討します。
あなたの場合、提供された情報に基づいて、列を1対1のテーブルから「車両」テーブルに移動したいと思います。
データベースに格納されるすべての値を管理するエンティティ、関係、および属性を識別する適切な ER モデルがある場合。エンティティごとにテーブルを作成し、エンティティのインスタンスごとに一意の値を持つ識別列を作成します。
リレーションシップの外部キーを追加します。多対多の関係の場合、テーブルを追加して外部キー ペア (またはトリプレットなど) を保持します。1 対 1 の関係の場合、2 つのエンティティ テーブルを 1 つに結合することを検討してください。関係がオプションの場合は、テーブルを分けておきたいかもしれませんが、次のタグで概説されている手法を使用してください: shared-primary-key
これにより、取得したようなデータベース スキーマが生成された場合、ほとんどの目的にはおそらく十分です。そうでない場合は、スキーマの変更を検討してください。