私は、人々がどこにいるかを見つけ、さまざまなアプリからどこに行くかをマップするために使用される ASP.NET MVC Web アプリケーションを設計しています。システムには、ユーザーごとに約 3 か月前の大量の位置データが含まれる可能性があります。私は現在、このために MS SQL 2008/2012 データベースを設計する方法を決定しようとしています。
単純に、次の列を持つ場所の更新のテーブルがあります。
ID (整数)
ユーザー ID (整数)
緯度（倍）
経度 (倍精度)
速度 (整数)
DateSent (日時)
私の読書によると、テーブルを分割することがこれを達成するための最良の方法であるようです。それが本当なら、データを「今日」、「今週」、「先週」、「前月」などのパーティションに分割する方法が自動化される方法について少し混乱しています。バックアップに使用されるすべてのものの 1 つの大きなアーカイブを持つ。
役立つ可能性のある技術的な要件をさらに提供できる場合は、戦略を考案してお知らせください。データベースの専門家からの洞察に感謝します。
注：これを知っているかどうかはわかりませんが、テーブルパーティションは高価なエンタープライズ機能です. データの量がアップグレードを正当化することを確認する必要があります。
a) クエリ用の論理グループに基づいてテーブルを分割する場合。「今日」、「今週」、「先週」、「前月」は、クエリがそのような粒度でない限り意味をなさない。より可能性が高いのは、習慣と習慣の変化を追跡することです。例えば。今月、先月、3ヶ月前。次に、4 か月の終わりに、3 か月前のデータ (現在は 4 か月前のデータ) があったパーティションを切り替えます。
b) テーブル パーティションは、基本的にパーティションを全体の一部として扱います。パーティション関数とスキーマをセットアップしたら、移動などについて心配する必要はありません。たとえば、月ごとにパーティション分割して 3 か月分のデータを保持する場合、5 つのファイル グループをセットアップします。1 は翌月、3 は「当月」、1 は「古い」月です。
c) 必要でない限り、「すべて」の歴史的な大規模なアーカイブを保持しないことを強くお勧めします。これら 3 つのアプリが 10 分ごとに GPS データを送信していると仮定しますか? つまり、1 人 1 日あたり 144 回、または 1 か月あたり 4320 回の挿入です。または年間51840。これは一人当たりだと言いましたよね？
最初に戻って、要件について少し考える必要があると思います。つまり、何人の人のためにこれを設計しているのかということです。このデータの保存から取得しようとしているデータは何ですか...次に、それに応じてデータベースを設計し、設計と要件がエンタープライズ版を正当化するかどうかを確認します。