2

南フロリダの都市の一人当たりの水使用量を追跡するためのデータベースを作成しています。

約40000人のユーザーがいて、それぞれが毎日の読み取り値をアップロードしています。

データベースを設定する方法を考えていたので、各ユーザーに個別のテーブルを与える方が簡単なようです。これにより、サーバーは数千万のエントリを含むテーブルを並べ替える必要がなくなるため、データのダウンロードが容易になります。

私は自分の論理に誤りがありますか？
テーブル名にインデックスを付ける方法はありますか？
速度を上げ、レイアウトを十分にシンプルに保つためにDBを設定する他の方法はありますか？

-ありがとう、
ジャレド

ps読み出しに不可欠なデータは次のとおりです。-locationID
（私の考えではテーブル名）
-Reading
-ReadDate
-ReadTime

この会話中にpps、私は5kテーブルをアップロードし、サーバーがフリーズしました。〜.O
あなたの助けに感謝します

4

4 に答える 4

8

何千ものテーブルを設定するのは良い考えではありません。1つのテーブルを維持し、そのテーブルにすべてのエントリを配置する必要があります。MySQLは驚くほど大量のデータを処理できます。発生する最大の問題は、データベースのサイズではなく、一度に処理できるクエリの量です。int属性を使用して数値を処理する場合、および適切なサイズのunsignedテキストの使用を処理する場合（テキストが大量に使用される場合を除く）。varchartext

ユーザーの処理ユーザー とレコードを識別する必要がある場合は、次のような別のテーブルを設定します。

  • user_id INT（10）AUTO_INCREMENT UNSIGNED PRIMARY
  • 名前VARCHAR（100）NOT NULL

レコードをユーザーにリンクする必要がある場合は、ユーザーのを参照するだけuser_idです。レコード情報については、SQLを次のように設定します。

  • id INT（10）AUTO_INCREMENT UNSIGNED PRIMARY
  • u_id INT（10）UNSIGNED
  • 読書あなたの読書がどのように見えるかわかりません。数字のINT場合はテキストを使用する場合VARCHAR
  • read_time TIMESTAMP

読み取りの日付と時刻をに統合することもできますTIMESTAMP。

于 2012-08-21T03:35:46.533 に答える
5

ユーザーごとに個別のテーブルを作成しないでください。

ユーザーおよび日付などの他の一般的な制約を識別する列にインデックスを保持します。

最後にデータをどのようにクエリするかを考えてください。いったいどのようにして、すべてのユーザーからの1日のデータを合計しますか？

主キーが心配な場合は、LocationID、Date複合キーを保持することをお勧めします。

編集：最後に（そして私はこれをいい意味で意味します）、データベース設計についてこの種の質問をしている場合、あなたはこのプロジェクトの資格があると確信していますか？頭を抱えているようです。自分の限界を知り、プロジェクトを通過させる方が、多くの作業を生み出し、結果に満足できない方法でプロジェクトを実装するよりも良い場合があります。繰り返しになりますが、私は「しない」と言っているのではなく、彼らが期待しているレベルまでこれを行うことができるかどうかを自問しただけです。多くのユーザーが常にそれを使用しているようです。何千人ものユーザーにプロジェクトを提供しながら、特定のことを学ぶことは、非常に高圧の環境である可能性があると私は言っていると思います。

于 2012-08-21T03:37:04.600 に答える
4

一般的に言えば、テーブルは物事のセットを表す必要があります。あなたの例では、あなたが持っているセットを簡単に特定できます。そこでは、理論的に最良の構造は、これら2つのテーブルを持つことであり、読み出しエントリにはユーザーのIDへの参照があります。

MySQLは非常に大量のデータを処理できるため、最善の策は、ユーザー読み取り構造を試して、そのパフォーマンスを確認することです。または、MongoDBやCouchDBなどのドキュメントベースのNoSQLデータベースを調べることもできます。これは、読み出しレポートを個別のドキュメントとして保存することも適切な選択であるためです。

于 2012-08-21T03:40:09.437 に答える
2

ユーザーごとの月間合計を含む要約テーブルを作成する場合、それがシステムの主な使用法になるはずですよね？

毎月、数値を計算し、合計を2番目のテーブルに格納します。ログテーブルは、12か月ごとに整理できます。つまり、古いデータを隅に詰めてインデックスを小さく保つことができます。これは、都市が詐欺で告発された場合にのみアクセスする必要があるためです。

したがって、毎日の読み取り値をどのように保存するかは、それについて気が狂う必要があるほど大きな問題ではありません。各ユーザーに独自のテーブルを提供することは、適切な解決策ではありません。大量のデータがある場合は、MongoDBなどを介したシャーディングを検討することをお勧めします。

于 2012-08-21T03:57:05.493 に答える