1

Sql 2008 (それ以前は '05) で、ほぼ 3 年間、データベースを運用しています。うまくいきましたが、あまりパフォーマンスが高くありません。そのため、スキーマとクエリを微調整して、いくつかの処理を高速化しています。また、メイン テーブルのスコアには、テーブルごとに約 1 ～ 3 ミルの行が含まれています (サイズの推定値を与えるため)。

サンプルのデータベース ダイアグラムを次に示します (Soz、NDA に基づいているため、元の図を表示できません) :-

代替テキスト http://img11.imageshack.us/img11/4608/dbschemaexample.png

注意すべきこと（これは私の問題に直接関係しています）：-

  • ビークルには 0 (NULL) または 1 つのラジオがあります。(左外部結合)
  • 車両には 0 (NULL) または 1 つのカップホルダー (左外側結合) を設定できます。
  • 車両には 1 つのタイヤ タイプ (内部結合) があります。

まず、これは正規化されたデータベース スキーマのように見えます。私はDB理論が嫌いなので、これは（少なくとも）3NFだと思います...有名な最後の言葉:)

これら 2 つの外部結合と内部結合が頻繁に呼び出され、多くのステートメントでさらにいくつかの結合が行われるため、データベースのパフォーマンスが低下しています。

これを修正するために、 indexed viewを試してみようと思いました。ビューの作成は簡単です。しかし、インデックスを作成しても機能しません->結合または自己参照テーブルを使用してインデックス付きビューを作成できません(別の問題:( )。

それで、私は何時間も泣いて（そして/ wrists 、髪を染めて、それについてのエモソングを書いて、それをmyfailspaceに載せました）、次のことをしました...

  1. 「オプション」の各外部結合テーブル (この例では、ラジオとカップホルダー) に新しい行を追加しました。ID = 0、残りのデータ = 'Unknown Blah' または 0's.
  2. 親テーブルを更新して、NULL データが 0 になるようにします。
  3. 外部結合から内部結合への関係を更新します。

これで動作します。インデックス付きビューを作成することもできます。これは現在非常に高速です。

だから...私は苦しんでいます。これは、私が教えられてきたことすべてに反しています。汚い気がします。1人。感染した。

これは悪いことですか？これは、パフォーマンスのためにデータベースを非正規化する一般的なシナリオですか?

これについていくつか考えてみたいと思います:)

PS。Google がランダムに見つけたこれらの画像は、私ではありません。

4

4 に答える 4

1

データベースは常に設計され、最初は3NFで実装されている必要があります。しかし、世界は理想ではなく現実の場所であり、パフォーマンス上の理由から2NF（または1NF）に戻すことは問題ありません。それについて自分を打ち負かさないでください、実用主義は現実の世界で常に独断主義を打ち負かします。

あなたの解決策は、それがパフォーマンスを改善するのであれば、良いものです。誰も製造しておらず、機能も持たない実際のラジオ（たとえば）を持っているという考えは悪いことではありません-それは以前からたくさん行われています、私を信じてください:-)そのフィールドをNULLとして使用する唯一の理由はどの車両にラジオがなく、これらのクエリにほとんど違いがないかを確認します。

select Registration from vehicles where RadioId is null
select Registration from vehicles where RadioId = 0

私が最初に考えたのは、4つのテーブルを1つにまとめて、重複データの問題を解決することでした。DBMSの問題のほとんどは、ストレージスペースの不足ではなくパフォーマンスの低下に起因します。

現在の非正規化スキーマも遅くなった場合は、フォールバックポジションとしてそれを維持するかもしれません。

于 2009-07-09T01:35:45.500 に答える
0

私は、パフォーマンスと学業の卓越性という同じ問題に直面しています。300 列と 91000 レコードを含む顧客データベースの大きなビューがあります。外部結合を使用してビューを作成していますが、パフォーマンスはかなり悪いです。ビューで一意のインデックスを有効にするために、結合する列に (null の代わりに) ゼロの値を持つダミー レコードを配置することにより、内部結合に変更することを検討しました。

パフォーマンスが重要である場合、それを実現するために時々奇妙なことをしなければならないことに同意しなければなりません。最終的に、請求書を支払う人は、アーキテクチャが完璧かどうかなど気にしません。

于 2009-09-09T21:40:40.500 に答える
0

「...だから、スキーマとクエリを微調整して、いくつかのことを高速化しています...」-これについては異議を唱えたいと思います。あなたは物事を遅くしているようです。（冗談だ。）

データベース プログラマーのブログが好きです。彼は、正規化を支持するコラムと反対するコラムを 2 つ持っています。参考になるかもしれません。

  1. http://database-programmer.blogspot.com/2008/10/argument-for-normalization.html
  2. http://database-programmer.blogspot.com/2008/10/argument-for-denormalization.html

私は DBA ではありませんが、パフォーマンスが低下しているという証拠が目の前にあると思います。これらの 1 対 1 の関係を個別のテーブルに分割することに何のメリットがあるのか​​わかりませんが、喜んで説明を受けます。

何かを変更する前に、SQL Server に遅いクエリごとに EXPLAIN PLAN を依頼し、その情報を使用して何を変更する必要があるかを正確に確認します。正規化の第一人者がそう言ったので、推測しないでください。あなたがしていることをバックアップするためのデータを取得します。あなたがしていることは、プロファイリングなしで中間層コードを最適化するように聞こえます。直感はあまり正確ではありません。

于 2009-07-09T01:21:09.177 に答える