1

これはより理論的な質問であり、特定のシナリオではありません。

次のような単純化されたテーブルスキームがあると仮定します。

代替テキスト

itemsいくつかの基本データ、item_data各アイテムの追加プロパティが含まれrel_items、異なるアイテム間のツリー関係を設定します。さまざまな種類のアイテム（フィールドで表されるitems.item_type）があり、さまざまなフィールドが格納されていitem_dataます。たとえば、犬、猫、マウスなどです。

いくつかの結合と接続詞を含むより大きなクエリがある場合（親アイテムが他のアイテムといくつかの条件を持つアイテムを取得するなど）、これは、すべての異なるタイプのアイテムを別々のテーブルに分割する場合と比較して、パフォーマンスの問題になる可能性があります（dog、cat、mouse）そしてそれらを単一のものにマージしませんか？

すべてを1つの基本的なアイテムテーブルにまとめると、ビュー（犬、猫、マウス）の作成はパフォーマンスに何らかの影響を与えますか？

編集（以下にコメント）：「種」、「ハウスペット」などをitem_typesと考えました。タイプごとに異なるプロパティがあります。基本的なアイテムテーブルとitem_dataテーブルを使用する目的は、基本的な「オブジェクト」を持ち、データベーススキームを変更することなく、必要な数のプロパティをそれらにアタッチすることです。たとえば、アプリケーションに含まれる動物の数とそのプロパティがわからないため、ユーザーが新しい動物を作成するたびに変更する必要のないデータベーススキームを考えました。

4

3 に答える 3

1

いくつかの結合を含むより大きなクエリがある場合、これは、すべての異なるタイプのアイテムを別々のテーブル（犬、猫、マウス）に分割し、それらを1つのテーブルにマージしない場合と比較して、パフォーマンスの問題になる可能性がありますか？

いいえ。

すべてを1つの基本的なアイテムテーブルにまとめると、ビュー（犬、猫、マウス）の作成はパフォーマンスに何らかの影響を与えますか？

いいえ。

個別のテーブルは、それらが根本的に異なることを意味します-異なる属性または異なる操作（または両方が異なる）

同じテーブルは、それらが基本的に同じもの、つまり同じ属性と同じ操作であることを意味します。

パフォーマンスは最初の考慮事項ではありません。

意味が最初の考慮事項です。

これらの意味と、アイテム間の実際の機能依存性を整理したら、結合のパフォーマンスを検討できます。

「犬、猫、ネズミ」はすべて哺乳類です。1つのテーブル。

「犬、猫、ネズミ」は、2匹の肉食動物と1匹の雑食動物です。2つのテーブル。

「犬、猫、ネズミ」は、従来のハウスペット2匹と従来の害虫1匹です。2つのテーブル。

「犬、猫、ネズミ」は、1匹のかっこいい動物と2匹の厄介な動物です。2つのテーブル。

「犬、猫、ネズミ」は3つの異なる種です。3つのテーブル。

それは意味についてです。

于 2010-12-03T11:11:17.223 に答える
1

データベースの設計時に分析および含まれなかった新しいオブジェクトに対応できるスキーマを構築する試みは、リレーショナルデータベースの議論で何度も出てくるアイデアです。

古典的なリレーショナルデータモデリングでは、議論の世界について主張される特定の命題に照らして関係を考案することができます。これらの命題は、データのユーザーがデータベースからデータを取得することによって取得できるという事実です。基本関係は、データベースに何かを格納することによってアサートされます。派生関係は、基本関係の操作によって取得できます。リレーショナルデータモデルをガイドとして使用してSQLデータベースを構築すると、基本リレーションがテーブルになり、派生リレーションがビューになります。

ただし、これらはすべて、データベースの設計が始まる前のデータ分析中に属性が検出されることを前提としています。

実際には、過去25年間、ほとんどのデータベースは、後で不完全または不正確であることが明らかになった分析に基づいて構築されてきました。その後、データベースは新しく改善された分析に照らして改訂され、改訂されたデータベースではアプリケーションコードのメンテナンスが必要になる場合があります。確かに、リレーショナルモデルとSQLデータベースは、プレリレーショナルデータベースよりも少ないアプリケーション依存関係を作成しました。

しかし、スキーマを変更せずにあらゆる主題に対応できる、あなたのような一般的なデータスキーマを考え出すのは自然なことです。このアプローチには結果があり、単なるパフォーマンスの問題よりもはるかに大きなコストがかかります。小規模なプロジェクトの場合、これらのコストは非常に管理しやすく、完全に汎用的なスキーマがそのような場合にうまく機能する可能性があります。

しかし、数十のエンティティタイプと、それらのエンティティとそれらの関係に基づく数百の関連する提案がある非常に大きなケースでは、「主題にとらわれない」スキーマを構築しようとすると、多くの場合、災害が発生します。これらの開発災害は十分に文書化されており、大規模な災害には数百万ドルの無駄な労力が伴います。

そのようなアプローチが災害につながる必要があることをあなたに証明することはできません。しかし、他の人の過ちから学ぶことは、それらを繰り返すリスクを冒すよりもはるかに価値があることがよくあります。

于 2010-12-03T12:50:37.393 に答える
0

確かに、結合されたテーブルのデータへのアクセスは常に遅くなります。ただし、適切なインデックスを使用すると、許容できる速度低下（2倍など）が許容される場合があります。

クエリで使用する一般的なアイテムをアイテムテーブルに移動し、表示する必要のある値のみをitem_dataに残します。これは、WhEREおよびJOIN条件では使用されません。

于 2010-12-03T11:08:00.063 に答える