2ちゃんねるのような、以下の条件を満たすスレッド型掲示板を作るとしたら、

データベース(MySQL)はどのようなテーブル設計になりますでしょうか?

・1つのスレッドにレスできる数は1000まで
・スレッドは、理論上無限に作成できること
・どんなに古いスレッドでもレスが1000個以内なら書き込みができ、最新のスレッド一覧に反映されること
・スレッド名が重複しないこと(可能なら)

例えるなら、2ちゃんねるでいう「dat落ち」のない掲示板です。
なお、サーバー1台あたりの処理は有限で、複数組み合わせて行く前提でお願いします。

よろしくお願いします。

回答の条件
  • 1人2回まで
  • 登録:2010/01/08 17:43:35
  • 終了:2010/01/15 11:03:22

ベストアンサー

id:KeyKey No.4

KeyKey回答回数29ベストアンサー獲得回数42010/01/08 21:51:44

ポイント31pt

基本的にhoronictさんの考えと同じです。

  • threads
id(PK) integer スレッドID
status_id(INDEX) integer 状態
subject varchar スレッド名
res_count integer レスポンス数
ipaddress varchar 投稿者IP
useragent varchar 投稿者UA
created datetime 作成日
updated datetime 更新日

  • responses
id(PK) integer レスポンスID
status_id(INDEX) integer 状態
thread_id(INDEX) integer スレッドID
body text 本文
ipaddress varchar 投稿者IP
useragent varchar 投稿者UA
created datetime 作成日
updated datetime 更新日

  • status
id(PK) integer ステータスID
name varchar 状態(公開・削除etc..)

必要によりスレッド用のステータスとレスポンス用のステータス2つ用意


レス数が1000まで、スレッド名の重複を禁止などは

データベース側ではなくアプリケーション側でチェックするのが良いかと思います。

(レスポンスが1000になったときのステータスを用意して、その場合レス送信フォームを表示させないなど)


スレ毎のレス数ですが、スレッド一覧などに表示する機会が多いのであれば上記の通りスレッドテーブルに持ち、

特に表示することがないのであれば取っ払ってしまい必要に応じてレスポンステーブルからCOUNTで取れば良いかと思います。

前者の場合逐一スレッドテーブルに更新が入るので最新スレッド一覧のSELECTをするのはそちらから

後者の場合特にスレッドテーブルを更新する必要がないのでレスポンステーブルからSELECTすることになります。

この辺の設計は規模と運用により正解が変わるので最適な方法を模索してください。


サーバ1台の処理は有限で複数組み合わせるということですが

簡単な方法ではスレッドID単位で横に切り分けるといったものが考えられます。

スレッド1~1000まではサーバA、1001~2000はサーバB・・・といったものです。


長期的に運用すると、基本的に古いスレッドは参照のみになるので

更新専用のマスターと参照専用のスレーブといった構成にすることも有効かと思います。

(マスタ->スレーブで非同期更新する)

id:xxmasaxx

肝はスレッドテーブルをいかに管理するか、ですね。

回答有り難うございます。参考にさせて頂きます。

2010/01/11 21:56:34

その他の回答(3件)

id:masahikokimoto No.1

masahikokimoto回答回数241ベストアンサー獲得回数102010/01/08 17:49:03

ポイント5pt

本質的な回答ではないのでポイントは結構です。

多分掲示板程度なら、DBMSを使うよりもファイルシステムをそのまま使ったほうが速いと思います。

もちろんファイルシステムの性能にも依存しますが。

id:xxmasaxx

すみませんが、今回はあくまでもDBでの構築という話でお願いします。

2010/01/08 18:13:12
id:ekkun22 No.2

ekkun22回答回数35ベストアンサー獲得回数12010/01/08 18:30:00

ポイント28pt

1掲示板に1テーブル

スレが違う場合はテーブル名が別。

テーブルは、動的に作成

ここまで決まったら、あとは自動的に決まると思いますけど・・・。

id:xxmasaxx

返信遅れましたが、理論上スレッドを無限に作成できる、ということがポイントです。

こちらでこの方法が思いつかなかったので今回質問してみました。

2010/01/11 21:47:16
id:horonict No.3

horonict回答回数257ベストアンサー獲得回数512010/01/08 18:39:48

ポイント26pt

こんな感じで2つのテーブルになるのではないでしょうか。アスタリスクはキー項目を意味します。

スレッド名の重複を避けたいのであれば、スレッド作成時にスレッド管理テーブルのスレッド名が重複しないことをチェックした方がいいでしょう。キーにする必要はないと思います。


スレッド管理テーブル

  • スレッドID(bigint)*
  • スレッド名(text)
  • 書き込み日時(datetime or tinytext)
  • 書き込みIP(varchar)
  • 削除フラグ(bool)

レス・テーブル

  • スレッドID(bigint)*
  • スレッド番号(int)**
  • 本文(text)
  • 書き込み日時(datetime or tinytext)
  • 書き込みIP(varchar)
  • 削除フラグ(bool)
id:xxmasaxx

遅れましたが回答有り難うございます。

今回の場合、レステーブルは問題なさそうですが、スレッドが無限に増える、ということを考えるとスレッド管理テーブルが一杯になった時が問題になりますね。

その場合、スレッド管理テーブルを、更に管理するテーブルが必要とか安直に考えたり。。

2010/01/11 21:51:59
id:KeyKey No.4

KeyKey回答回数29ベストアンサー獲得回数42010/01/08 21:51:44ここでベストアンサー

ポイント31pt

基本的にhoronictさんの考えと同じです。

  • threads
id(PK) integer スレッドID
status_id(INDEX) integer 状態
subject varchar スレッド名
res_count integer レスポンス数
ipaddress varchar 投稿者IP
useragent varchar 投稿者UA
created datetime 作成日
updated datetime 更新日

  • responses
id(PK) integer レスポンスID
status_id(INDEX) integer 状態
thread_id(INDEX) integer スレッドID
body text 本文
ipaddress varchar 投稿者IP
useragent varchar 投稿者UA
created datetime 作成日
updated datetime 更新日

  • status
id(PK) integer ステータスID
name varchar 状態(公開・削除etc..)

必要によりスレッド用のステータスとレスポンス用のステータス2つ用意


レス数が1000まで、スレッド名の重複を禁止などは

データベース側ではなくアプリケーション側でチェックするのが良いかと思います。

(レスポンスが1000になったときのステータスを用意して、その場合レス送信フォームを表示させないなど)


スレ毎のレス数ですが、スレッド一覧などに表示する機会が多いのであれば上記の通りスレッドテーブルに持ち、

特に表示することがないのであれば取っ払ってしまい必要に応じてレスポンステーブルからCOUNTで取れば良いかと思います。

前者の場合逐一スレッドテーブルに更新が入るので最新スレッド一覧のSELECTをするのはそちらから

後者の場合特にスレッドテーブルを更新する必要がないのでレスポンステーブルからSELECTすることになります。

この辺の設計は規模と運用により正解が変わるので最適な方法を模索してください。


サーバ1台の処理は有限で複数組み合わせるということですが

簡単な方法ではスレッドID単位で横に切り分けるといったものが考えられます。

スレッド1~1000まではサーバA、1001~2000はサーバB・・・といったものです。


長期的に運用すると、基本的に古いスレッドは参照のみになるので

更新専用のマスターと参照専用のスレーブといった構成にすることも有効かと思います。

(マスタ->スレーブで非同期更新する)

id:xxmasaxx

肝はスレッドテーブルをいかに管理するか、ですね。

回答有り難うございます。参考にさせて頂きます。

2010/01/11 21:56:34

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません