問題タブ [denormalization]

私はこれを持っています：

User.serials.episodesに対していくつかの操作を実行したいのですが、これはあらゆる種類の巧妙なトリックを意味することを私は知っています。理論的には、すべてのエピソードデータをシリアル化（非正規化）してから、必要に応じてgroup_bySiteに入れることができます。

クエリする必要のあるエピソードがたくさんある場合、これは悪い考えですか？

ありがとう

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

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

2つのセカンダリインデックスを持つ「メッセージ」テーブルがあるとします。

• "recipient_id"
• "sender_id"

「メッセージ」テーブルを「recipient_id」でシャーディングしたい。特定の受信者に送信されたすべてのメッセージを取得する方法では、1つのシャードにクエリを実行するだけで済みます。

しかし同時に、特定の送信者から送信されたすべてのメッセージを要求するクエリを作成できるようにしたいと思います。ここで、そのクエリを「メッセージ」テーブルのすべてのシャードに送信したくありません。これを行う1つの方法は、データを複製し、「message_by_sender」テーブルを「sender_id」でシャーディングすることです。

このアプローチの問題は、メッセージが送信されるたびに、「message」テーブルと「message_by_sender」テーブルの両方にメッセージを挿入する必要があることです。

しかし、「message」に挿入した後、「message_by_sender」への挿入が失敗した場合はどうなりますか？その場合、メッセージは「message」に存在しますが、「message_by_sender」には存在しません。

メッセージが「message」に存在する場合、2フェーズコミットに頼らずに「message_by_sender」にも存在することを確認するにはどうすればよいですか？

これは、データベースをシャーディングする人にとっては非常に一般的な問題であるに違いありません。どのように対処しますか？

この質問を読んだ後、非正規化は単純化のための解決策ではないことがわかりました。この場合はどうですか？

サイト記事が公開される予定のリストを含むニュース記事があります。後者は、テーブルまたは多対多の関係 (クロステーブルを介して) のいずれかによって正規化された方法で表現できます。しかし、単純な解決策は、sites-article-will-be-published-to (publish_to_site_1、publish_to_site_2 など) に対して多数のブール値を投入することです。サイトが次のとおりであると仮定します。

1. 数が少ない
2. 時間が経っても変わらない
3. 名前を除いて、フィールド自体はありません

これはまだひどい考えですか？多対多の関係はやや面倒に思えますが、私は以前にこのような場合にそれを行ったことがあります (そして面倒に思えました)。

注:私はこれを Rails で行っていますが、それほど面倒ではありません。一方、メタプログラミングは、このようなことを些細なことにします。

Oracle では、テーブル クラスタは、共通の列を共有し、関連するデータを同じブロックに格納するテーブルのグループです。テーブルがクラスター化されている場合、1 つのデータ ブロックに複数のテーブルの行を含めることができます。たとえば、ブロックは、1 つのテーブルだけではなく、employees テーブルと departments テーブルの両方からの行を格納できます。

http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/tablecls.htm#i25478

これは SQLServer で実行できますか?

データベースに保存する必要のある大きな記事がある場合、それぞれが多くのテーブルに関連付けられていると、NoSQLオプションが役立ちますか？1000文字の記事を複数の「バケット」にコピーして、バケットに関連するたびに複製する必要がありますか、それとも多くのMemcacheを備えた正規化されたMySQL DBを使用する必要がありますか？

私が以下に提供した情報に基づいて、別々のテーブルを異なるタイプの契約を保持する1つのテーブルに非正規化するのが良い考えかどうかについてあなたの意見を教えてください？..賛否両論は何ですか？..誰かがこれを試みましたかbefore？..銀行システムはCIF（顧客情報ファイル）[マスター]を使用します。顧客はさまざまな種類の口座、CD、住宅ローンなどを持ち、トランザクションコード[種類]を使用しますが、それらを1つのテーブルに保存しますか？

ローン、購入、販売のトランザクション用に別々のテーブルがあります。これらの各テーブルの行は、次の方法で対応する顧客に結合されます。

これらのテーブルには、ポーン、購入、販売という同じ商品を中心に展開する共通のプロパティが非常に多いため、これらを「契約」という1つのテーブルに統合して実験し、次の列を追加しました。

シナリオ：

顧客は最初に商品をポーンし、2回の利息を支払い、次にその商品を質屋に販売することを決定します。質屋は商品を在庫に入れ、最終的に別の顧客に販売します。

たとえば、次のような汎用テーブルを設計しました。

ローン契約では、ポーンの元本を保持し、購入では購入価格を保持し、販売では販売価格を保持します。

このデザインは良いアイデアですか、それとも別々に保つ必要がありますか？

シナリオ：

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

アプローチ：

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

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

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

中央のテーブルArticleがあり、独自のテーブルに多くのリビジョンがあるwikiシステムがあります。リビジョンにはそれぞれ、created_atの時刻と日付の列が含まれています。

最新のリビジョンの名前フィールドからの非正規化フィールドsort_nameを含むようにArticlesを更新したいと思います。

各Articleのsort_nameフィールドに最新のリビジョンのnameフィールドを入力するために発行できるSQLコマンドは何ですか？

その価値については、私はPostgreSQLを使用しています。

バックグラウンド：：：：

Java 用の Google アプリ エンジン (GAE) を使用しています。大きなテーブルの長所と短所に対応するデータ モデルの設計に苦労しています。これらは以前の 2 つの関連記事です。

• データベース設計 - Google アプリ エンジン
• 予定と品目

ほとんどのクライアント要求が 1 つのクエリだけで処理できるように、非正規化されたプロパティがエンティティに追加された完全に正規化されたバックボーンを暫定的に決定しました。

私は、完全に正規化されたバックボーンは次のようになると考えています。

• 非正規化で間違いをコーディングした場合、データの整合性を維持するのに役立ちます
• クライアントの観点から 1 回の操作で書き込みを有効にする
• データに対するあらゆるタイプの予期しないクエリを許可します (待機する意思がある場合)。

非正規化されたデータは次のようになります。

• ほとんどのクライアント要求を非常に高速に処理できるようにする

基本的な非正規化手法:::

「ファンアウト」と呼ばれる手法を説明するアプリ エンジンのビデオを見ました。アイデアは、正規化されたデータへの迅速な書き込みを行い、タスク キューを使用して、クライアントを待たせることなく舞台裏で非正規化を完了することです。参照用にここにビデオを含めましたが、その長さは 1 時間であり、この質問を理解するために見る必要はありません: http://code.google.com/events/io/2010/sessions/high-throughput -data-pipelines-appengine.html

この「ファンアウト」手法を使用すると、クライアントが一部のデータを変更するたびに、アプリケーションは 1 回のクイック書き込みで正規化されたモデルを更新し、非正規化命令をタスク キューに送信するため、クライアントは待機する必要がなくなります。それらも完了する必要があります。

問題：：：

タスク キューを使用してデータの非正規化バージョンを更新する際の問題は、タスク キューがそのデータの非正規化を完了する前に、変更したばかりのデータに対してクライアントが読み取り要求を行う可能性があることです。これにより、最近の要求と一致しない古いデータがクライアントに提供され、クライアントが混乱し、アプリケーションにバグがあるように見えます。

解決策として、URLFetch を介してアプリケーション内の他の URL への非同期呼び出しを介して、非正規化操作を並行して展開することを提案します。http://code.google.com/appengine/docs/java/urlfetch/ アプリケーションは、すべてのクライアント要求に応答する前に、非同期呼び出しが完了していました。

たとえば、「予定」エンティティと「顧客」エンティティがあるとします。各予定には、誰が予定されているかについての顧客情報の非正規化されたコピーが含まれます。顧客が名前を変更した場合、アプリケーションは 30 回の非同期呼び出しを行います。影響を受ける各予定リソースに 1 つずつ、それぞれの顧客の名前のコピーを変更します。

理論的には、これはすべて並行して実行できます。この情報はすべて、データストアに 1 回または 2 回の書き込みを行うのにかかるおおよその時間で更新できます。非正規化が完了した後、タイムリーな応答をクライアントに行うことができ、クライアントが不適合なデータにさらされる可能性を排除できました。

これに関する最大の潜在的な問題は、アプリケーションが一度に 10 を超える非同期リクエスト呼び出しを実行できないことです (ここに文書化されています): http://code.google.com/appengine/docs/java/urlfetch/overview .html )。

提案された非正規化手法 (再帰的非同期ファンアウト):::

私が提案する解決策は、非正規化命令を別のリソースに送信して、命令を再帰的に同じサイズの小さなチャンクに分割し、各チャンク内の命令の数が完全に実行できるほど小さくなるまで、小さなチャンクをパラメーターとして自分自身を呼び出すことです。たとえば、30 件の予定が関連付けられている顧客が名前のスペルを変更したとします。非正規化リソースを呼び出して、30 件の予定すべてを更新するように指示します。次に、これらの命令を 3 つの命令の 10 セットに分割し、3 つの命令の各セットで独自の URL に対して 10 の非同期要求を作成します。命令セットが 10 未満になると、リソースは各命令に従って完全に非同期要求を作成します。

このアプローチに関する私の懸念は次のとおりです。

• アプリ エンジンのルールを回避しようとしていると解釈される可能性があり、問題が発生する可能性があります。（URLがそれ自体を呼び出すことさえ許可されていないため、実際には、相互に呼び出す再帰を処理する2つのURLリソースが必要です）
• これは複雑で、潜在的な障害点が複数あります。

このアプローチに関する意見をいただければ幸いです。