正規化とパフォーマンス:(この)スキーマ内のリンクテーブルを削除する利点/問題?

一般的に、私は自分のデータベースをできる限りクリーンで拡張可能なものにしたいと考えています。

しかし、いくつかのテストを行った後、大規模なデータセットを扱うときには、通常これを実行する最善の方法ですが、問題の「ダーティ」なアプローチよりもはるかに遅いことがわかりました。

基本的に私はオブジェクトのテーブルを持っていると言うことができます。これらのオブジェクトは特定の人に属します。私の最初の考えは、私がいつものように、私のオブジェクトのためのオブジェクトテーブル、私の人のための人々テーブル、そしてobject_to_peopleリンカテーブルを作成することでした。

ただし、オブジェクトとリンカテーブルを結合してすべてのオブジェクトを取得するには、最大約3秒かかることがあります(これは400kレコードに基づいていますが、オブジェクトあたり1つのリンクのみに基づいています)。はい、インデックスのe.c.tを設定します。試して物事をスピードアップする

If I instead remove the people and linker table, and put the people in the objects table as columns and use 1/0 to set whether each person is assigned to that object, without joining the two large tables i see a speed of around 0.3 -> 0.7 seconds (varied greatly).

まず、2人だけが必要です。しかし、もし私がそれを助けることができれば、私はあまりにも制限的であることを望んでいません。私はキャッシングを使用することができ、エンドユーザのタイミングを改善しないことを知っていますが、リンクテーブルではなくカラムを使用することは実際には悪い考えです。

5
インデックスを正規化して使用します。
追加された 著者 Don Roby,
読み取り(SELECT)は高速化できますが、書き込み(INSERT、UPDATE、DELETE)は遅くなる傾向があります(通常、より多くの制約を適用する必要があるため)。非正規化を行うかどうかは、アプリケーションの読み込みと書き込みのバランスによって決まります。 MySQLはインデックス付きビュー(マテリアライズドビュー)をサポートしていません。
追加された 著者 Ted Hopp,
ここでは、正規化に関する良い情報をお届けします。
追加された 著者 Ibu,
ノーマライズ。別々の「カテゴリ」列を追加する唯一の時間は、「カテゴリ」のリストがよく理解され、制限されている場合です。あなたのケースでは、あなたは人々のリストが成長すると期待しています - あなたは正常化しないという決定を支払うでしょう - 私は約束します:-)
追加された 著者 drdwilcox,
@PST。それは本当だ。私は指数を述べるべきだった。
追加された 著者 drdwilcox,
挿入は本当に問題ではありません。 「People」テーブルはほとんど更新されません。私は、ウェブサイトがライブになった後のことを推測しています。翌年には2回の更新と挿入が行われます。オブジェクトテーブルは、急速に成長する可能性がありますが、データがいっぱいになるにつれてデータを入力する時間が短くなります。 SELECT以外のものはすべて管理上の終わりです。私はいつものリンカーテーブルに固執し、何が起こるか見ることができます。私は、完全なソリューションの全体的なポイントは、そのソリューションのすべてが(e.c.tをキャッシュする)部分を演じていることです。返信のための乾杯
追加された 著者 Lee,
スキーマ関連の質問では、小さな絵が遠ざかります。
追加された 著者 user166390,
@drdwilcoxしかし、それはパフォーマンスの問題に対処していません - 正規化されたフォームを高速化する(またはACIDの必要条件がより少ない可能性が高いクエリを作成する)ためにできることは何ですか?
追加された 著者 user166390,

4 答え

私は同様のセットアップをしています。
私の結合テーブルには17,000,000行があります。私の "person"テーブルは840万行あり、 "objects"テーブルは300000行あります。

私は、ジョインテーブル上の複数のジョインと、何万行もの結果を返し、実行に1秒未満かかる結果(50〜400ミリ秒)を組み合わせたクエリを持っています。

あなたの最初のレイアウトはうまくいくと思いますが、おそらくあなたのインデックスとクエリに集中する必要があります。

2
追加された

1つのオブジェクトが複数の人物に同時に属している可能性がある場合は、リンクテーブルを保持してください。

0
追加された
perofrmanceまで - クエリの説明を表示するかもしれません...
追加された 著者 Randy,

しかし、これは本当に悪い考えであると考えられる何らかの理由があります   リンクテーブルではなく列を使用しますか?

あなたが得たパフォーマンス以上にスケーラビリティを重視するなら、実際には悪いアイデアだと言います。

スケーラビリティよりも優れたパフォーマンスを評価するなら、それは本当に良いアイデアだと思います。

0
追加された

また、巨大なテーブルのmysqlの alter table は非常に長い時間実行することができるので、アプリケーションの新しいユーザを追加することは合理的な時間には不可能です。

0
追加された