# 一般的な会員制サイトのデータベース構成について
当方はサーバーサイドについてド素人なのですが、会員制サイトの制作にチャレンジしようとしています。
気になったのは通常の一般的な会員制サイトではデータベースの構成をどのようにしているのかということです。
例えば会員がそれぞれブログを持って投稿できるようなサイトの場合、
blog_appというデータベースを作成し。その下に会員テーブルを作成しここで会員の管理をしますよね?
もちろん、ここで会員は、管理画面において自分の投稿した記事や情報についてしか参照できないとします。
他の会員の情報にはアクセスできません。
では会員それぞれが記事を投稿する場合、その記事はどのように管理するのが一般的なのでしょうか。
考えられる構成としては
(1)postsテーブルを用意し、そこに全員の投稿と投稿者IDを記録して、会員ごとのブログ記事を表示する場合はIDでフィルタリングして表示する。
つまりテーブルひとつに全員の投稿を記録して管理する。
(2)会員ごとにデータベースにユーザーを作成して、ユーザーごとのpostsテーブルを複製して、そこへの権限を与えて、投稿・管理する。
ド素人の見解としては
(1)のほうが管理が楽ですが、一人分のデータを参照したいのに対していちいち全員分のデータが格納された所からフィルタリングして参照しなければならないので、非効率な面があるように思えます。
全員分の投稿をひとつのテーブルで記録してるのですぐにデータが肥大化するようにも思えますし。
(2)は一人の会員ごとに専用のテーブルを持つので参照が楽な反面、データベースのユーザーが煩雑になりそうです。
なので(1)のほうがどちらかというと現実的に思えます。
一般的にはどのような構成になっているのでしょうか。教えて下さい。
みんなの回答 2 件
結論から言うと、文句なしで①を採用します。テーブルを乱立させるのはご法度です。
おそらくMySQLなどのRDBを使用されていると思いますが、オープンソースのRDBはYahooやTwitterなど世界的サービスでも今現在問題なく稼働しているように、大量レコードを捌く能力を持ち合わせています。
もちろん上に挙げたようなサイトはmemcachedを使用したり、サーバをスケールアウトしてそれぞれ管理するIDを割り振ったりと涙ぐましい努力によって成り立っていますが、数万レコードレベルならインデックスを貼って適切にSQLを発行すれば大きな問題にはならないでしょう。
更新クエリを頻繁に発行しなければクエリキャッシュが効くので、それより大きなオーダーであっても1ms以下のラグにしかならないはずです。
フレームワークのActiveRecordによるアソシエーションのイメージで、会員IDを外部キーとしてブログテーブルからその都度検索する形になります。
MVCのフレームワークを使用すれば自ずと型が定まり、あれこれ思案せずに構築できると思いますので、フレームワークの使用をオススメします。
nosqlを視野に入れると分かりやすいかもしれませんね。
近年、なぜ、nosqlが注目されたのか。
答えはおのずと1になると思います。
関連するトピックス