データベース(MySQL)はどのようなテーブル設計になりますでしょうか？
・1つのスレッドにレスできる数は1000まで
・スレッドは、理論上無限に作成できること
・どんなに古いスレッドでもレスが1000個以内なら書き込みができ、最新のスレッド一覧に反映されること
・スレッド名が重複しないこと(可能なら)
例えるなら、2ちゃんねるでいう「dat落ち」のない掲示板です。
なお、サーバー1台あたりの処理は有限で、複数組み合わせて行く前提でお願いします。
よろしくお願いします。
基本的にhoronictさんの考えと同じです。
| id(PK) | integer | スレッドID |
|---|---|---|
| status_id(INDEX) | integer | 状態 |
| subject | varchar | スレッド名 |
| res_count | integer | レスポンス数 |
| ipaddress | varchar | 投稿者IP |
| useragent | varchar | 投稿者UA |
| created | datetime | 作成日 |
| updated | datetime | 更新日 |
| 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 | 更新日 |
| id(PK) | integer | ステータスID |
|---|---|---|
| name | varchar | 状態(公開・削除etc..) |
必要によりスレッド用のステータスとレスポンス用のステータス2つ用意
レス数が1000まで、スレッド名の重複を禁止などは
データベース側ではなくアプリケーション側でチェックするのが良いかと思います。
（レスポンスが1000になったときのステータスを用意して、その場合レス送信フォームを表示させないなど）
スレ毎のレス数ですが、スレッド一覧などに表示する機会が多いのであれば上記の通りスレッドテーブルに持ち、
特に表示することがないのであれば取っ払ってしまい必要に応じてレスポンステーブルからCOUNTで取れば良いかと思います。
前者の場合逐一スレッドテーブルに更新が入るので最新スレッド一覧のSELECTをするのはそちらから
後者の場合特にスレッドテーブルを更新する必要がないのでレスポンステーブルからSELECTすることになります。
この辺の設計は規模と運用により正解が変わるので最適な方法を模索してください。
サーバ1台の処理は有限で複数組み合わせるということですが
簡単な方法ではスレッドID単位で横に切り分けるといったものが考えられます。
スレッド1～1000まではサーバA、1001～2000はサーバB・・・といったものです。
長期的に運用すると、基本的に古いスレッドは参照のみになるので
更新専用のマスターと参照専用のスレーブといった構成にすることも有効かと思います。
（マスタ->スレーブで非同期更新する）
本質的な回答ではないのでポイントは結構です。
多分掲示板程度なら、DBMSを使うよりもファイルシステムをそのまま使ったほうが速いと思います。
もちろんファイルシステムの性能にも依存しますが。
すみませんが、今回はあくまでもDBでの構築という話でお願いします。
１掲示板に１テーブル
スレが違う場合はテーブル名が別。
テーブルは、動的に作成
ここまで決まったら、あとは自動的に決まると思いますけど・・・。
返信遅れましたが、理論上スレッドを無限に作成できる、ということがポイントです。
こちらでこの方法が思いつかなかったので今回質問してみました。
こんな感じで2つのテーブルになるのではないでしょうか。アスタリスクはキー項目を意味します。
スレッド名の重複を避けたいのであれば、スレッド作成時にスレッド管理テーブルのスレッド名が重複しないことをチェックした方がいいでしょう。キーにする必要はないと思います。
遅れましたが回答有り難うございます。
今回の場合、レステーブルは問題なさそうですが、スレッドが無限に増える、ということを考えるとスレッド管理テーブルが一杯になった時が問題になりますね。
その場合、スレッド管理テーブルを、更に管理するテーブルが必要とか安直に考えたり。。
基本的にhoronictさんの考えと同じです。
| id(PK) | integer | スレッドID |
|---|---|---|
| status_id(INDEX) | integer | 状態 |
| subject | varchar | スレッド名 |
| res_count | integer | レスポンス数 |
| ipaddress | varchar | 投稿者IP |
| useragent | varchar | 投稿者UA |
| created | datetime | 作成日 |
| updated | datetime | 更新日 |
| 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 | 更新日 |
| id(PK) | integer | ステータスID |
|---|---|---|
| name | varchar | 状態(公開・削除etc..) |
必要によりスレッド用のステータスとレスポンス用のステータス2つ用意
レス数が1000まで、スレッド名の重複を禁止などは
データベース側ではなくアプリケーション側でチェックするのが良いかと思います。
（レスポンスが1000になったときのステータスを用意して、その場合レス送信フォームを表示させないなど）
スレ毎のレス数ですが、スレッド一覧などに表示する機会が多いのであれば上記の通りスレッドテーブルに持ち、
特に表示することがないのであれば取っ払ってしまい必要に応じてレスポンステーブルからCOUNTで取れば良いかと思います。
前者の場合逐一スレッドテーブルに更新が入るので最新スレッド一覧のSELECTをするのはそちらから
後者の場合特にスレッドテーブルを更新する必要がないのでレスポンステーブルからSELECTすることになります。
この辺の設計は規模と運用により正解が変わるので最適な方法を模索してください。
サーバ1台の処理は有限で複数組み合わせるということですが
簡単な方法ではスレッドID単位で横に切り分けるといったものが考えられます。
スレッド1～1000まではサーバA、1001～2000はサーバB・・・といったものです。
長期的に運用すると、基本的に古いスレッドは参照のみになるので
更新専用のマスターと参照専用のスレーブといった構成にすることも有効かと思います。
（マスタ->スレーブで非同期更新する）
肝はスレッドテーブルをいかに管理するか、ですね。
回答有り難うございます。参考にさせて頂きます。
肝はスレッドテーブルをいかに管理するか、ですね。
回答有り難うございます。参考にさせて頂きます。