問題タブ [denormalization]

stackoverflow のような高トラフィック Web サイトのデータベース設計と正規化のベスト プラクティスは何ですか?

正規化されたデータベースを使用して記録を保持するか、正規化された手法を使用するか、または両方を組み合わせて使用​​する必要がありますか?

正規化されたデータベースを記録管理用のメイン データベースとして設計して冗長性を減らし、同時に高速検索のために別の非正規化形式のデータベースを維持することは賢明ですか?

また

メイン データベースは非正規化する必要がありますが、高速なデータベース操作のためにアプリケーション レベルで正規化されたビューを使用する必要がありますか?

または他のアプローチ？

この質問の当然の帰結として、一度に 1 つのテーブルに常にアクセスするために RDMBS を使用して結合の最適化と体系的な非正規化を行うことの利点について相談し、伝えることができる優れた比較研究があるかどうか疑問に思っていました。

具体的には、次の情報が必要です。

• パフォーマンスまたは正規化と非正規化。
• 正規化されたシステムと非正規化されたシステムのスケーラビリティ。
• 非正規化の保守性の問題。
• 非正規化によるモデルの一貫性の問題。

私がここでどこに行くのかを見るためのちょっとした歴史: 私たちのシステムは社内のデータベース抽象化レイヤーを使用していますが、それは非常に古く、複数のテーブルを処理することはできません. そのため、すべての複雑なオブジェクトは、関連する各テーブルで複数のクエリを使用してインスタンス化する必要があります。システムが常に単一のテーブルを使用するようにするために、テーブル全体で体系的な非正規化が使用され、場合によっては 2 ～ 3 レベルの深さでフラット化されます。nn 関係に関しては、データ モデルを慎重に作成して、そのような関係を回避し、常に 1-n または n-1 にフォールバックすることで、問題を回避したようです。

最終結果は、顧客がしばしばパフォーマンスについて不満を述べる、入り組んだ過度に複雑なシステムです。そのようなボトルネックを分析するとき、彼らはシステムが基づいているこれらの基本的な前提に決して疑問を抱かず、常に他の解決策を探します.

私は何か見落としてますか ？私は全体の考えが間違っていると思いますが、どういうわけかそれを証明 (または反証) するための反論の余地のない証拠を欠いています.アプローチは間違っています（一貫したデータモデルについて、私があまりにも妄想的で独断的であることを私に納得させます）。

私の次のステップは、独自のテスト ベンチを構築して結果を収集することです。

---- 編集注 : システムは最初、データベース システムのないフラット ファイルで構築されました...クライアントが Oracle を使用するシステムを主張したため、後でデータベースに移植されました。リファクタリングは行わず、既存のシステムにリレーショナル データベースのサポートを追加しただけです。フラット ファイルのサポートは後に削除されましたが、データベースを活用するためのリファクタリングをまだ待っています。

ここでの私の最初の質問です。

私は経験の浅い開発者で、この問題に悩まされています。

監査可能にする必要があるテーブルがあります。このテーブルに、コール センターからの電話が記録されているとします (そうではありませんが、これは単なる例です)。私はそれを「CallHistory」と呼びます。

私は当初、呼び出し先の名前、電話番号などを含む「Callees」という別のテーブルを保持することを計画していました。このテーブルは代理主キーを使用します。

CallHistory テーブルには、Callee テーブルへの外部キーがあります。

もともとこれを行ったのは、呼び出し先の電話番号を変更すると、システム全体に伝播し、複数のテーブルで電話番号を変更する必要がなくなるためです。

問題は、CallHistory テーブルの要点は、ダイヤルミス (発信者が間違った番号をダイヤルしたなど) を含む通話の履歴を記録することです。この代理キー アプローチを使用すると、履歴が失われます。

職場の上級開発者の 1 人は、履歴を保存するために、特定の時間に発信者がダイヤルするたびに電話番号のコピーを CallHistory テーブルに保持することを提案しました。

同じ目的で監査/変更ログテーブルを保持することを考えていました。

私のアプローチはこの目的に十分でしょうか、それとも完全に軌道から外れていますか? どちらのアプローチを好みますか?

乾杯、アンドリュー

私は小規模な SQL Server '08 データベースの実装について判断を下そうとしています。

フラットファイル データベースの出力テキスト ファイルを古い COBOL システムから前述の SQL Server データベースに変換しています。これは、レンダー ID (7 桁の数字)、銀行口座番号 (15 桁)、および「口座サフィックス」 (2 桁) の組み合わせによって一意に識別できる、車両および不動産ローンのデータベースです。

データベース管理に関しては、私はかなりナイーブであることを告白します (正直に言うと、現在のポジションまで実際に行ったことはありません)。他のいくつかのテーブルにインデックスを付けるキー:

1) 上記の値の 3 列のキーを使用して各ローンを識別します。または
2) 3 つの値を組み合わせた 24 文字の文字列である「キー」列を実装して、データを非正規化します。

非正規化は醜いのは当然ですが、銀行間でローンをやり取りしたり、ローンの接尾辞を変更したりすることはできないため、更新の異常が発生することは予想できません。これらの値の変更は、別のアカウントであることが保証されています。

複合キーはより洗練されていますが、それが悪いことであると示唆する論文をいくつか読んだことがあります。

では、どちらのオプションがより良い選択になる可能性が高く、さらに重要なことに、その理由は?

そのため、次のようなコードを書いていることがよくあります。

song.rb:

つまり、利便性のために非正規化されたデータを保持するsortable_nameデータベース列があり、モデルの名前が変更されるたびにデータを入力したいと考えています。

このロジックをこのような構造にカプセル化できるようにしたいと思います

か何か。これは存在しますか？

彼女が話す言語をチェックしてデータベースに保存するようにユーザーに提供するとします。重要な注意点として、検索用に別の検索エンジンがあるため、これらの値をデータベースで検索することはありません。さて、これらの値を保存する明白な方法は、次のようなテーブルを作成することです。

ただし、サイトの負荷が高くなり、可能な限りオーバーヘッドを排除するように努めているため、UIで結果を表示するときにメインメンバーテーブルとの結合を回避するために、ユーザーの言語をメインテーブルに保存して保持することを考えていました。 「12,34,65」のようにカンマ区切り

繰り返しますが、私はそれらを検索しないので、その列で全文索引を作成する必要はありません。

このソリューションに問題はありませんが、何か見落としていますか？

ありがとう、アンドレイ

RailsとMySQLを使用していますが、行のカウントに基づく効率の質問があります。

私はそのProjectモデルを持っていhas_many :donationsます。

プロジェクトのユニークなドナーの数を数えたいです。

projectsテーブルにと呼ばれるフィールドがありnum_donors、新しいドナーが作成されたときにそれをインクリメントするのは良い考えですか？

それとも@num_donors = Donor.count(:select => 'DISTINCT user_id')、データベースの最適化のおかげで、効率の点で類似または同じになるようなものですか？user_idこれには、カウントしたい他のフィールドのインデックスを作成する必要がありますか？

寄付総額の合計についても同じ答えが当てはまりますか？

新しいプロジェクトを開始しましたが、非常に正規化されたデータベースがあります。ルックアップできるものはすべて、ルックアップ テーブルへの外部キーとして格納されます。これは正規化されていて問題ありませんが、最も単純なクエリに対して 5 つのテーブル結合を行うことになります。

いくつかのものを非正規化することをお勧めします。州コードのように。私が生きている間に州コードが変更されることはありません。3文字の代理店コードと同様の話。これらは代理店の代理店によって配布され、変更されることはありません。

状態コードの問題と 5 つのテーブル結合について DBA に連絡したとき。「正常化された」「結合が速い」という反応が返ってきました。

非正規化する説得力のある議論はありますか? 他に何もなければ、私は正気のためにそれをします。

T-SQL での同じクエリ:

現在の状況では、トピックは3つの主要なカテゴリでソートされています。3つ以上のカテゴリを追加する可能性がありますが、上位のアップは、トピックに1つ以上のカテゴリを追加する機能を実装したいと考えています。

私の元のデータベース設計では、トピック情報テーブルの外部キーとしてcategoryIDがあります。これは最初からおそらく悪い考えでしたが、カテゴリが3つしかないように設定されていて、この方法でクエリを実行できるようになると思いました。

したがって、私が見ることができることから、2つのオプションがあります。1）phpの最後で解析するコンマ区切りの文字列としてcategoryIDを入力します。2）DBを再構築し、categoryIDをcategoryIDとtopicIDの独自のテーブルに引き出します。

みんなどう思ったのかしら。私の最初の本能は、データベースを再構築することでした。しかし、私が考えるときの最初のオプションは、実装するのが最も簡単で、データベースを変更することによって既存のものを壊す可能性が最も低いです。ただし、これにより非正規化が発生し、データに一貫性がなくなる可能性があります。

パフォーマンスと引き換えに一貫性のないデータが発生するリスクを受け入れる限り、非正規化は問題ないことを読みました。あなたの意見では、私はこのリスクのパフォーマンスで多くを得るでしょうか？この状況で私が何をすべきかについての意見をいただければ幸いです。

助けてくれてありがとう、
リーバイス

概要 （漠然と申し訳ありませんが、もっと詳しく説明すると、物事が複雑になりすぎると思います）

私には3つのテーブルがあり、テーブル1にはIDが含まれ、テーブル2には独自のIDとテーブル1のIDが含まれ、テーブル3には独自のIDとテーブル2のIDが含まれます。

私は多くの時間を熟考してきましたが、テーブル3に関連するテーブルのIDも含める方が効率的だと思います。

-3つのテーブルを結合する必要がないことを意味します。テーブル3をクエリするだけです（非常に頻繁に使用されるクエリの場合）

-テーブル1の特定のIDを含むテーブル3内の行をロックするだけで、予約システムをより簡単に実装できるようになります。

データベースレイアウトについてもっと知りたい人のために、ここにもっと情報があります

質問

非正規化の不利な点は何ですか？完全に反対している人もいれば、正しい状況を信じている人もいるので、それは便利なツールです。IDは変更されないので、同じデータを2回挿入する必要があり、追加のスペースが消費されることを除いて、実際には不利な点はありません（IDであるため、無視できる程度です）。