私は、世界中の 300 以上のリモート販売拠点を管理する販売組織向けの統計追跡システムを設計しています。システムは、売上高に関する毎日のレポートを受け取ります (生のドルの値、および X アイテムの販売数などの情報統計)。
システムの構築にはMAMPを使用しています。
これらの数値を 1 つの MySQL 大きなテーブルに格納することを計画しているため、各行は 1 つの場所からの 1 日の統計です。以下にサンプルを示します。
------------------------------------------------------------------
| LocationID | Date | Sales$ | Item1Sold | Item2Sold | Item3Sold |
------------------------------------------------------------------
| Hawaii | 3/4 | 100 | 2 | 3 | 4 |
| Turkey | 3/4 | 200 | 1 | 5 | 9 |
------------------------------------------------------------------
組織は毎日 300 か所のそれぞれから統計の更新を受信する可能性があるため、1 か月以内にテーブルに 9,000 件のレコードがあり、1 年以内に約 108,000 件になると見積もっています。したがって、年に基づいた MySQL テーブルのパーティショニングは、クエリを 100,000 レコードの範囲に維持する必要があり、これにより、時間の経過とともに安定したパフォーマンスが得られると思います。
（上記の「背景データ」の理論に問題がある場合は、気軽に言及してください。大規模なデータベースを構築した経験がなく、これは単にネットで検索して集めたものです。）
現在、このシステムのフロント エンドは Web ベースであり、主に PHP に重点を置いています。オンラインで見つけた YUI フレームワークを使用して、グラフ情報を表示する予定です。
組織が確認する必要があるのは、遠隔地の売上高の日次/週次グラフと、販売されたアイテムなどの「内訳」統計 (通貨グラフに「ドリルダウン」して、その収入の何パーセントが発生したかを確認できるようにするため) です。項目 X から)。
したがって、LocationID ごとの統計がある場合、この情報を大陸ごとに整理するのは非常に簡単です。システムがヨーロッパのすべての場所の売上高のグラフを表示する必要がある場合、「大陸」カテゴリを指定する LocationID のディメンション テーブルを結合するクエリを実行して、それらの数値をすべて (日付別に) 合計し、それらをグラフに表示します。または、週ごとの情報を表示するには、特定の週の日次レポートをすべて合計し、JSON 配列として JS グラフ オブジェクトに返します。私が見る限り、かなり単純なもの。
さて、私の考えは、これらの一般的なクエリの「要約」テーブルを作成することでした。ユーザーがアフリカの過去 3 か月の売上高を取得したい場合、クエリは毎日のレベルまで下げて、さまざまな WHERE 句と JOIN 句を使用して、適切な LocationID の数値を週ごとに合計し、次に、ユーザーに表示します...まあ、粒度の低いテーブルを使用する方が効率的であるように見えました。このようなテーブルは、新しい日報によってメイン テーブルに自動的に更新される必要があります。
次に存在する必要があるデータの階層の種類を次に示します。
1) 地域別日別数値 2) 地域別日別数値に基づく大陸別日別数値 3) 大陸別日別数値に基づく惑星日別数値
4) 地域別週次数値に基づく地域別週次数値 5) 地域別週次数値に基づく大陸別週次数値 6) 大陸別週次数値に基づく惑星の週次数値
したがって、ここには一種のツリーがあり、最も詳細な情報が一番下に (確かに 1 つのテーブルにあります)、一連のより詳細でない一連のテーブルがあるため、長期的なクエリのデータを簡単に取得できます (パーティション分割)。地球の週ごとの数字の 3 年間のクエリを受け取った場合、年ごとの日ごとの数字テーブルは役に立ちません)。
さて、最初の質問ですが、これは本当に必要なのでしょうか? 私が説明しているシナリオで大規模なクエリ効率を達成するためのより良い方法はありますか?
これを行うための特に良い方法がないと仮定すると、これをどのように行うのですか?
いわば「更新をカスケードする」ことができるように思われる MySQL Triggers を発見しました。Daily Figures テーブルへの INSERT の後、理論的には、トリガーは挿入されたレコードの情報を読み取り、その値に基づいて、上位レベルのテーブルの適切なレコードで UPDATE を呼び出すことができます。つまり、4 月 12 日にジョージアで 100 ドルが発生すると、米国テーブルの「4 月 10 日から 4 月 17 日」のレコードが、その範囲内のすべての日次レコードの合計で更新されます。もちろん、新しく入力された 100 ドルと新しい値は正しいでしょう。
理論的には可能ですが、ハードコーディングされすぎているようです。組織が場所を追加/削除し、どの大陸にいるかを設定できるようにシステムを構築したいと考えています。これは、その LocationID を含めるようにトリガーを再構成する必要があることを意味します。特定のコマンドとテーブルに対して複数のトリガーを作成できないということは、トリガー データを個別に保存するか、トリガー オブジェクトから抽出してから、追加または削除する特定のルールをイン/アウトして解析するか、外部データを保持する必要があることを意味します。このステップの前に PHP で処理した配列、または...基本的に、面倒な作業が山ほどあります。
最初は MySQL トリガーが私の救いのように思えましたが、必要な方法でそれらを実装するのがどれほど難しいかを調べれば調べるほど、私がこれをどのように行っているかについて完全に的外れであるように思えます。より経験豊富なデータベース担当者からフィードバックを得ることができます。
私がやろうとしていることを達成する方法についての技術的なアドバイスを含む知的な回答に感謝しますが、正しい行動 (それが私がしていることであっても) とそれが正しい理由を説明する賢明な回答をより深く感謝します.