database-design - Webアプリケーションでのデータベース設計のヒント

Question

誰かがWebアプリケーションのデータベース設計に関するヒント/アドバイスを持っていますか？私が取り組んでいるアプリケーションが離陸して多くの使用を開始した場合に、将来的に多くの時間/労力を節約できるようなものです。

もう少し具体的に言うと、このアプリケーションは戦略ゲーム（ブラウザベース、テキストのみ）であり、ほとんどの場合、データベースに保存されて後で処理される「注文」を発行するプレーヤーが関与し、結果もそこに保存されます（履歴「注文」とそれに対応する結果はおそらくかなり大きくなるでしょう）。

詳細を追加するために編集（要求に応じて）：

プラットフォーム：Django

データベースエンジン：MySQLの使用を考えていました（別のデータベースを使用することに大きな利点がない限り）

スキーマ：私が今持っているのはいくつかのDjangoモデルだけですが、ここに投稿するには詳細が多すぎます。そして、スキーマの投稿を開始すると、これは具体的になりすぎて、一般的なヒントを探していました。たとえば、後で処理される「注文」を発行し、ある種の「履歴」を表示するために保存する必要のある結果を返すとします。この場合、「履歴」用に別のテーブルを作成する方がよいのでしょうか、それとも「注文」と結果の両方を集計するテーブルを作成する方がよいのでしょうか。「履歴」テーブルをキャッシュできると思いますが、集計テーブルで新しい行を変更するのではなく、常に新しい行を作成する必要があるため、データベース内のスペースとデータベース操作が多くなります。

Answer 1

高いスケーラビリティと一般的なパフォーマンスを実現するための設計という、より大きな問題に触れたことがあるでしょう。

基本的に、データベース設計では、頻繁に使用されると予想されるデータに外部キーとインデックスを追加し、データを小さなテーブルに分割して正規化し、頻繁に読み取るデータと読み取るデータを特定するなどの優れたプラクティスに従います。頻繁に書かれ、最適化されます。

ハイ パフォーマンス Web アプリケーション用のデータベース設計よりもはるかに重要なのは、クライアント レベルでの HTML ページ キャッシングと、サーバー レベルでのキャッシュ データまたは動的ファイルの代わりに静的ファイルを提供することの両方で、キャッシングを効果的に使用することです。

キャッシングの優れた点は、必要に応じて追加できるため、アプリケーションが軌道に乗ったときにそれに応じて進化できることです。

履歴データに関する限り、これは頻繁に変更されるとは考えていないため、キャッシュするのに最適です。データから定期的でかなり集中的なレポートを作成する場合は、実行中に Web アプリケーションが停止しないように、このデータを別のデータベースに配置することをお勧めします。

もちろん、この種の最適化は、アプリケーションがそれを保証すると思わない限り、実際には必要ありません。

Answer 2

データベースの正規化と、インデックスをよく考えることは、見逃せない2つのことです。特に、SELECTSがUPDATEよりもはるかに頻繁に発生するゲームを検討する場合。

長期的には、memcachedも確認する必要があります。これは、ユーザーが数人を超える場合は常にデータベースクエリがボトルネックになる可能性があるためです。

Answer 3

今持っているスキーマを投稿してみませんか? 使用するプラットフォームとデータベース、および提案しているテーブル構造の詳細がなければ、有用に答えるには広すぎる質問です...

Answer 4

1 つのクエリで 6 つ以上のテーブルを結合して、頻繁にヒットするレポート タイプの Web ページのデータを取得する場合は、テーブルを非正規化する必要があります。また、Hibernate や ActiveRecord などの ORM ライブラリを使用する場合は、それらが生成するデフォルトのマッピングと最終的に生成される SQL に時間を費やすようにしてください。データベースへの 1 回の往復で同じ結果が得られる場合、データベースとのやり取りが非常に多くなる傾向があります。