6

データベースを設計しており、データベースを正規化したいと考えています。1 つのクエリで、約 30 ~ 40 のテーブルを結合します。非常に人気になった場合、これは Web サイトのパフォーマンスに影響を与えますか? これがメインのクエリになり、50% の確率で呼び出されます。私が参加する他のクエリは、2 つのテーブルについてです。

今は正規化するかしないかの選択肢がありますが、将来正規化が問題になった場合、ソフトウェアの 40% を書き直さなければならず、長い時間がかかる可能性があります。この場合、正規化は本当に害になりますか? 時間があるうちに非正規化する必要がありますか?

4

5 に答える 5

4

私は引用します:「正確さのために正規化し、速度のために非正規化します-そして必要な場合にのみ」

私はあなたに言及します:データベースに関して、「正確さのために正規化し、パフォーマンスのために非正規化する」というのは正しいマントラですか?

HTH。

于 2010-04-24T00:13:54.000 に答える
3

パフォーマンスが懸念される場合、通常、非正規化よりも優れた代替手段があります。

  • 関連するテーブルに適切なインデックスと統計を作成する
  • キャッシング
  • マテリアライズド ビュー (MS SQL Server のインデックス付きビュー)
  • ほとんどの場合に使用される正規化されたテーブルに加えて、テーブルの非正規化されたコピー (それらを必要とするクエリにのみ使用) を用意します (同期コードを記述する必要があります。必要なデータ精度)
于 2010-04-24T00:34:22.857 に答える
1

正規化により、パフォーマンスが低下する可能性があります。ただし、これは時期尚早に非正規化する理由にはなりません。

完全な正規化から始めて、パフォーマンスの問題があるかどうかを確認します。あなたが説明している速度 (1 日あたり 1000 回の更新/挿入) では、テーブルが巨大でない限り、問題が発生することはないと思います。

また、使用できるデータベース最適化オプション (インデックス、プリペアド ストアド プロシージャ、マテリアライズド ビューなど) がたくさんある場合でも。

于 2010-04-24T00:45:19.447 に答える
1

多分私はここで何かを逃しています。しかし、単一のクエリで 30 ~ 40 のテーブルを結合する必要があるアーキテクチャの場合、そのクエリがサイトの主な用途であるとすれば、より大きな問題が発生します。

私は他の人に同意します。サイトを時期尚早に最適化しないでください。ただし、主なユースケースを考慮してアーキテクチャを最適化する必要があります。50% 以上の時間実行されるクエリの 40 テーブル結合は、最適化された IMO ではありません。

于 2010-04-24T02:47:59.693 に答える
0

初期の最適化を行わないでください。Web サイトを高速化する方法は、非正規化だけではありません。キャッシュ戦略も非常に重要です。30 ~ 40 個のテーブルのクエリがかなり静的なデータである場合、結果をキャッシュする方が最適化に適していることがわかります。

また、読み込み回数には書き込み回数も考慮してください。挿入または更新ごとに約 10 回の読み取りを行っている場合、データはかなり静的であると言えます。そのため、一定期間キャッシュする必要があります。

スキーマを非正規化してしまうと、書き込みのコストも高くなり、処理が遅くなる可能性もあります。

あまりにも多くの最適化を行う前に実際に問題を分析し、システム内のボトルネックが実際にどこにあるかを確認するのを待ちます。最初に何を最適化する必要があるかについて驚くことになるかもしれません。

于 2010-04-24T00:19:54.877 に答える