2012-06-29 9 views
6

です。この質問は、プログラマにもっと適しているかもしれません。その場合は、移行してください。実際に実行可能な結合の数は、

私は現在、典型的なデータモデルの複雑さを熟考しています。一方、データモデルを正規化する必要があることは誰もが知っていますが、正規化されたデータモデルでは後でデータを再構成するためにかなりの数の結合が必要になります。また、ジョインは、関係するテーブルのサイズに応じて、潜在的に高価な操作です。だから、私が把握しようとしている質問は、このトレードオフについてどうやって行くのだろう?私。実際にはデータモデルを設計するときに典型的なクエリで許容される結合数はどれくらいですか?これは、単一のクエリで複数の結合を数える場合に特に興味深いでしょう。

例として、家を所有するユーザーで、アイテムを含む引き出しを持つルームがあるとします。上記で説明した意味で、ユーザー、住居、部屋、引き出し、およびアイテムのテーブルを使ってこれを正規化すると、あるユーザーに属するすべてのアイテムを取得するときに5つのテーブルに参加する必要があります。これは私にとって非常に複雑なもののようです。

ほとんどの場合、テーブルのサイズが関係している可能性があります。小さなデータで5つのテーブルを結合することは、数百万の行を持つ3つのテーブルほど悪くありません。あるいは、この考え方は間違っていますか?

+1

テーブルはわずか4つのジョインです。本当に多くはありません。また、すべてのクエリで5つのテーブルすべてからのデータは必要ありません。テーブルが少ない(非正規化された)テーブルは、すべてのクエリで扱うテーブルが大きくなります。 –

+1

ypercubeのように、5つのテーブルは多くありません。 (私は通常、画面上に視覚的にフィットするように単一のクエリでテーブル結合を制限しようとしています。つまり、約20テーブル程度です:))しかし、サンプルアプリケーションでは、ほとんどの負荷はユーザーの項目クエリから来ています。ユーザーIDをアイテムテーブルに追加します。これにより、特定のクエリがはるかに高速になります。もちろん、競合するデータを作成しないようにレコードの挿入と更新のロジックを慎重に設計する必要があります。常にそうであるように、「1つのサイズはすべてに適合する」ソリューションではありません。 – Arvo

答えて

5

そこにはreasons for the Database Normalizationsがあります。私は20個以上のテーブルとサブクエリを組み合わせたクエリを見てきました。長い時間うまく動作しています。これまでの作業部分に影響を与えることなく、既存の作業アプリケーションに追加される新しい機能を導入することができるので、正規化の概念が大きな勝利であることがわかりました。

データベースはあなたの人生を容易にするためにさまざまな機能が付属しています:

  • (これはビューのための唯一のユースケースではありませんが)あなたが最も一般的に使用されるクエリのビューを作成することができます。
  • 一部のRDBMSでは、名前付きサブクエリと再帰的クエリを使用できるように、Common Table Expressions(CTE)が用意されています。
  • 一部のRDBMSでは、PL/SQLやPL/pgSQLなどの拡張言語が用意されているため、独自の関数を開発してスキーマの複雑さを隠し、API呼び出しのみでデータを操作できます。

How does a SQL statement containing mutiple joins work?に何らかの形で関連する質問がありました。それも調べる価値があるかもしれません。

正規化されたデータベースでアプリケーションを開発する方が簡単です。適切なアプローチでビュー/関数を使用してスキーマを分離し、アプリケーションコードをスキーマの変更から免れることができます。非正規化された設計を行う場合は、変更の可能性を犠牲にして非標準化されたシステムのパフォーマンスを最適化する傾向があるため、設計変更が多くの​​コードに影響します。

3

完全に正規化されたデータモデルは、パフォーマンス上のコストが高くなりますが、変更するのがより弾力的です。 1つのクエリに対して調整された1桁のデータモデルフラットは、パフォーマンスが大幅に向上しますが、仕様が変更されたときに価格を支払う必要があります。

多分、あなたのデータモデル(クエリ)の使用が大きく変わるのでしょうか?そうでなければ;それらを正規化しないでください(DBAに質問してください)。それ以外の場合は正規化し、多くの結合を使用する場合はクエリ実行プランだけで特定の番号を与えることはできません。

5

データベースを正規化すること自体が芸術的な形態です。
ジョインを正しく構成すると、必要な列だけを取得できます。
複数のテーブルを持つ数百万のレコードを持つクエリを実行し、必要なフィールドに参加するだけで、すべてのレコードを含む1つまたは2つのテーブルがあれば、はるかに速くなります。 2つ目の例では、すべてのデータを取得していますが、それをソートすることはコード化の悪夢となります。
MySQLは要求されたデータの取得だけで非常に良いです。
クエリが長いというだけでは、クエリが遅いというわけではありません。
私は非常に高速だった20行以上のコードを照会ステートメントでよく見てきました。

あなたが書いた質問を信じて、テストスクリプトを書いていない場合は自分で試してみてください。パフォーマンスは、これらの問題を解決することができる非正規化を使用して問題となる場合は

http://en.wikipedia.org/wiki/Database_normalization

:答えはであるあなたの質問を解決するために

+2

ああ、あなたの他の質問に答えてください。許容できる結合数はいくつですか?答えはそれが取る限り多くなります:) –

1

。そのステップを前もって考えてください(すでに予想される負荷がない限り)。それが本当に必要な時、測定に基づいて非正規化する。

関連する問題