デザインオピニオン：ユーザーのためのテンプレートデータベース/テーブル

Question

私のアイデアを跳ね返り、それがうまく動作するかどうかを知るために、プロのプログラマー/ DBAが必要です。下記を読んで、この理論を破る可能性のある情報を教えてください。ありがとう。

---

ウェブサイトのアイデアの概要：
のウェブサイトは、チャットフォーラムでの質問に答え、自分のカード/ボックスブレークを紹介するスポーツカードコレクターによって使用される、貿易/他のユーザーと/に販売し、カードのコレクションを保管してください。

デザインの問題：
ユーザーには無制限のカードを割り当てることができます。これはいくつかの非常に大きなテーブルのために作ることができます。

デザインの質問：私は、彼らがサイト上で自分のコレクションを持っていることができますどのように多くのカード上のユーザーを制限したくない
。彼らが1枚のカードを5枚持っていて、むしろカードごとに5枚の記録を持っていれば、それはその特権です。これは、各カードが異なる状態にある場合にも必要である。ただし、これを可能にすることで、すべてのレコードをすべてのユーザーに格納するテーブルが1つしかない場合でも、オプションに近いものではないことを意味します。私は1,000,000以上のカードを持つスポーツカードコレクターを知っています。

私は、ユーザーごとにテーブルまたはデータベースを作成すると、より高速なクエリが可能になると考えていました。すべてのデータベースは同じサーバー上にあるはずです（私は自分のホストが誰であるかはわかりませんが、現時点では設計段階にあります）。誰もが必要とするデータを持つメインデータベース（ユーザテーブル/データベースがベースアイテムを参照している間はベースアイテム）が存在します。フィールドが別のデータベースからの外部キーになる可能性があることがわかります。したがって、私の考えは可能ですが、全体的に私はベストアイデアが何であるか分かりません。

ほとんどのホストは「無制限のデータベース」と言いますが、これは各ユーザーのデータベースについて考えさせてくれます。私はスレッド、そのコレクションアイテム、それらのプリファレンス、およびその他の情報に関するそのユーザーの投稿にこれを使用できます。また、各ユーザーに異なる表/データベースを持たせることで、理由の如何にかかわらず誰かの表を再索引付けする必要がある場合、他のユーザーには影響しません。

しかし、私の最大の懸念は、テーブル/データベースの構造に対する追加/削除です。私はスクリプトが必要な変更を加えるために書かれていると確信していますが、それは非常に高いリスクのようです。たとえば、私は、各データベース内の特定のテーブル、または同様のテーブルのすべてにフィールドを追加するスクリプトを作成することはできますが、それが困難であることを証明できることを確認することができます。

---

あなたが私のためにそこに投げることができるアイデアは、非常に高く評価されます。私はこのサイトで1年以上働いていて、テーブルが大きすぎる、応答時間が遅い、ユーザー数が増えると、 phpmyadmin/MySQL。私はまた、データベースの建物の半分を取得し、それを行うより良い方法があると思うしたくない。私はそれを行うための複数の方法があるかもしれないが、それのための最も一般的な練習は何ですか？どうもありがとうございました。

Answer 1

ユーザーごとにテーブルまたはデータベースを作成することで、より高速なクエリが可能になると考えていました。

これは誤りです。単一のデータベースが高速になります。

1,000,000人のユーザーがいる場合を除き、1,000,000人のカードは本当に大きな数字ではありません。

複数のデータベースは管理上の悪夢です。単一のデータベースが常に優先されます。

---

テーブルの大きすぎる、遅い応答時間の私の心配、およびユーザーの数はphpMyAdminの/ MySQLの

によって設定されたいくつかの制約を破る、育てる場合は、ハード押されたことでしょうMySQLの制限を超えます。

スローレスポンスはアプリケーションの一部であり、SQLクエリの詳細は何よりも重要です。

最後に、そして最も重要です。

すべてのテクノロジが古いです。結局、はでなければなりません。アップグレードを余儀なくされるようになるには、まず何かを稼働させる必要があります。

何十億もの行があるまで「大きなデータベース」について心配しないでください。

すべてのソフトウェアテクノロジの有効期限が切れているため、「長期的な」ソリューションについて心配する必要はありません。早く。

---

ユーザー数について。

ウェブインタラクションの多くは、JavaScriptを介してブラウザとやりとりする時間がかかります。またはページを読む。クリックは実際にはまれです。合理的に大規模なサーバー上のMySQLは、30秒以上のほぼ同時のクエリを1秒未満の応答で処理する必要があります。 HTMLページの書式設定と送信を開始するには、アプリケーションの処理にはほとんど時間がかかりません。典型的なサーバー上の非常に良いクリップで物事を捉えることができます。

データベースデザインが恐ろしい全テーブルスキャンを回避する場合。

最も一般的なクエリに適切なインデックスが必要です。

今すぐ。ほとんど同時に30件のリクエストが発生する可能性はありますか？ユーザーが10秒ごとに1回だけクリックすると（ページを読み、フォームに記入し、ページを再読み込みし、ビールを飲みます）、1秒間に30回のクリックをする確率は300 同時ユーザー。人々が自分の人生で他に行うことを考えれば、50,000人以上のユーザーがいることを意味します（毎週あなたのサイトに1時間を費やしていると考える）。

Answer 2

私は、データ完全性の問題、参照整合性の問題、管理上の問題など、あらゆるユーザーのためのデータベース...

テーブルが正規化されインデックス化されている限り、私は数億の行を持つテーブルは非常に大きくなります。

代わりに、私は単純なテーブルデザインから始めます。あなたのサイトが大成功を収めている場合は、MySqlにpartitioningまたはshardingを実装するために余分な努力を払う必要はありません。

Answer 3

私はあなたの靴のどこで1つのデータベースと1つのテーブルから始め、テーブルの可能なサイズについて心配する必要はありません。あなたが成功し、あなたが想像している大きさに達すると、情報に基づいたより良い決定を下すために、おそらくあなたのドメインの多くのリソースと知識が必要になります。そのようなことが起こったら、HBase,MondgodbなどのSQLソリューションを考慮して、大きなデータを扱う企業が直面するいくつかの制限を考慮して水平方向のスケーリング（無制限サイズ）を考慮することもできます。 mysql partitionsまたは他のシャーディングソリューションを使用することもできます。だから、1つのテーブルで製品を構築し、絶対に必要となるまでこの問題を解決しないでください。がんばろう！