4

私は学区のデータベース（そのうちの15,000までと成長中）と、それぞれの従業員が利用できる退職計画/給付金を持っています。データはかなりよく正規化されています：

  • 地区レコードは、0またはnの退職プランオプションに関連付けられています（ n <10は3つの結合されたテーブルに分散しています）
  • 地区レコードは、0またはn個の利益に関連付けられています（ nは1つの結合されたテーブルから40に近い）
  • 地区は、関連の数がわずかである他のいくつかのものにも関連しています。

ここで、クライアントはレポートを作成します。そして、彼らは非常に動的な方法で報告したいと考えています（どの地区、計画、または利益の任意の資産に対してルールを追加/削除できるiTunesスマートプレイリストについて考えてみてください）。私は彼らが地区の財産、その退職計画またはその利益について質問し、すべてを返すことを許可する必要があります。

物事を単純に保ち（今のところ）、データの重複を避けるために、1つの地区のレコードが事実上1-を持っている方法でデータにアクセスできるようにするいくつかのビューを設定しました（shhh、私は知っています）ビューとの1対1の関係、all_retirement_plansおよびビューとの1対1のレコードall_benefits_plans。これにより、統一された結果セットをもたらすクリーンな結合セットが得られますが、明らかに、後でではなく早く発生する独自の問題セットが付属しています...

つまり、データが追加されるにつれて、途方もなく遅くなります。

非正規化に関するアドバイスを探しています。ビューが行うことを実行するレポートテーブルについて考えましたが、インデックスを付けることができます。また、この地区データのセット全体をMongoDB（または同様のもの）にダンプすることも考えました。他にも選択肢はあると思いますが、試行錯誤を繰り返しているので、ここの誰かが合理的な解決策の球場にいるような方法でアドバイスしてくれることを願っています。

肝心なのは、15,000までの（そして成長している）地区レコードを多くの追加のメタデータと一緒に保存し、そのデータを非常に詳細なレベルで報告できるようにする必要があるということです。誰かが私自身の考えが私を連れて行ったところを超えて何か考えやアドバイスがありますか？私は、私が知っている問題を先取りしようとしています。

4

1 に答える 1

0

最近、データをリレーショナルからドキュメント指向 (非正規化) に移行する作業を行ったので、これが役立つことを願っています。

データを Mongo に移動するためのいくつかのオプション:

  1. MySQL から Mongo にデータを書き込むだけで簡単にリレーショナル テーブルを保持できます。変換は必要ありません。データをそのまま移動するだけです。Mongo には、新しいコレクションに出力できる map/reduce があります。遅いけど。=( ビューを真上に移動すると、Mongo には、新しいドキュメントを生成するための非常に強力な集約フレームワークがあります。

  2. 理想的には、MySQL で「ドキュメント」を作成してから、それらを移動します。MySQL での私の経験は、ドキュメントを非常にフラットにすることです。group_concat を使って工夫することで、構造を追加できます。基本的に、いくつかのデータと手動の JSON 文字列を一緒に group_concat します。（醜いが、それは動作します）

  3. Mongo はドキュメントの操作に優れています。本当に、本当に素晴らしい。非正規化されたデータを操作する場合は、強くお勧めします。

  4. これはやり過ぎかもしれませんが、Mule ESB を使用して MySQL から Mongo にデータを移動します。そこではより複雑でトリッキーな変換を行うことができますが、学習曲線があります。

  5. SQL Server では、クエリを XML として出力できます。MySQL でそれを行うためのライブラリを見つけることができれば、XML から JSON へのジャンプは簡単です。SQL Server で 10 万レコードを超えるクエリを実行し、XML を非常に迅速に出力することができました。

ポイントの詳細について知りたい場合はお知らせください。=)

于 2013-02-22T01:27:49.823 に答える