3

シナリオ：

大きなシステム（〜200テーブル）。
60,000ユーザー。
複雑なレポートでは、レポートごとに複数のクエリを実行する必要があります。それらのレポートでさえ、あらゆる場所に内部クエリがあり、PHPでいくつかの処理が行われる複雑なクエリになります。

アプローチ：

よくわからないアプローチを見てき
ました。報告可能なシステム内のアクティビティを登録する、一元化された非正規化されたテーブルが1つあります。このテーブルは主に外部キーを保持するため、かなりコンパクトで高速である必要があります。
したがって、たとえば（私のシステムは仮想学習管理システムです）、ユーザーがコースに登録すると、テーブルにはユーザーID、日付、コースID、組織ID、アクティビティタイプ（登録）が格納されます。
もちろん、このデータも実際のアプリケーションが使用する正規化されたDBに保存します。

長所：データを処理して高速に取得するための、簡単で保守しやすいクエリとコード。
短所：非正規化されたテーブルが実際のDBと同期しなくなる危険性があります。

このアプローチは検討する価値がありますか、それとも（できれば経験から）合計$＃％＃％tですか？

4

3 に答える 3

2

非正規化されたテーブルを1つだけではなく、データウェアハウスを構築する必要があります。スタースキーマ、ディメンション、レベル、ファクトテーブルに関する情報をWebで検索します。または、この本を読んでください。ラルフキンボールのデータウェアハウスツールキット 1.77ドルのような中古品がいくつかありました。これは、基本的なデータウェアハウスの設計書であり、実際のアドバイスです。

于 2010-06-18T02:15:04.260 に答える
0

私は今あなたと同じアプローチを使用しています。

厳密に正規化されたデータベースは、クエリの速度を大幅に低下させる場合があります。また、クエリを実行するのが難しくなります。それは非常に真実です、誰もこの状態を否定することはできません。

一部の大企業（グーグル、ツイッター、フェイスブック）は、リレーショナルデータベースの概念を離れ始めています。彼らは、非常に多くの冗長コンポーネントを備えた独自のデータベースの概念を使い始めます。しかし一方で、それらの概念は、簡単で非常に高速なクエリをもたらします。

データベースのすべての変更がアプリケーションレベルでもチェックされることを常に保証できる一方で、あなたのアプローチは問題ないと思います。

よろしくお願いします

于 2010-06-18T03:20:41.967 に答える
0

正規化は学術的な概念です。非常に便利ですが、常にそれに固執するのは無意味です。トランザクションは、不整合を回避する方法です。10以上のテーブルの代わりに1つ持つことができるなど、より単純で効率的なクエリのニーズを満たす場合は、冗長性を利用してください。

于 2010-06-18T11:29:20.600 に答える