3

ユーザーとユーザーに関連する情報を格納するためのデータベースを持つシステムを設計しています。具体的には、テーブル内の各ユーザーにはほとんど情報がありません。名前、パスワード、 uid のようなもの。

次に、各ユーザーは 0 個以上のコンテナーを持ちます。私が最初にこれを行った方法は、コンテナーを保持し、それを所有するユーザーを参照するフィールドを持つデータベースに 2 番目のテーブルを作成することです。つまり、containerName, content, owner のようなものです。

したがって、コンテナからのデータに対するクエリは次のようになります。

SELECT content
  FROM containers
 WHERE (containerName='someContainer' AND owner='someOwner');

私の質問は、これが良い方法であるかどうかです。スケーラビリティを考えていると、数千人のユーザーがいて、それぞれに 5 つのコンテナーがあると考えています (ただし、各ユーザーは異なる数のコンテナーを持つことができますが、おそらく 5 が典型的なケースです) . 私の懸念は、1 つのクエリで必要な 5*1000 エントリのうち 5 つのエントリがある場合、データベースの検索が遅くなることです。(通常、クエリから特定のコンテナーのコンテンツのみが必要な場合があり、基本的に 4995 エントリのオーバーヘッドでデータベースを調べていますよね? そして、100 万人のユーザーをサブスクライブした場合、それは巨大なテーブルになります。直感的に悪い考えのように感じます。

私が持っていた2番目の方法は、ユーザーごとにテーブルを持つことですが、それはデータベースに1000個のテーブルを与えることになるため、(直感的にも)悪い方法のように見えるため、あまり良い解決策とは思えません。やれ。

これをどのように設計するかを理解する助けがあれば大歓迎です.すべてが明確で簡単に理解できることを願っています.

4

2 に答える 2

0

RBMS（Oracle / MySQL など）データベースであれば、頻繁にクエリされる列にインデックスを作成して、テーブル トラバーサルとクエリを最適化できます。PRIMARY キーと (オプションで) FOREIGN キーのインデックスが自動的に作成されます。

于 2012-05-18T07:46:34.170 に答える
0

これを処理する一般的な方法は、フィールドINDEX上にを作成することです。そのようにして、MySQL は条件ownerに対してクエリを最適化しました。owner = 'some value'

参照: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

1000 個のテーブルはスケーラブルではないと言っているのは正しいです。数百万のレコードに達し始めたら、シャーディング (ユーザー属性に基づいてレコードをいくつかの場所に分割する) を検討したくなるかもしれませんが、その時までにはすでにかなり成功していると思います ;-)

于 2012-05-18T07:44:57.573 に答える