2chのような掲示板のデータベース設計

Question

練習として2chのような掲示板を作りたいのですがデータベース構成をどのようにすればいいかわかりません

スレッドは理論上無限個
1スレッドにはレスを1000個までつけれる
こういう掲示板はどういう構成になっているのでしょうか？

今考えているのは、

テーブル1　[id:本文:タイトル:作成日:更新日]
テーブル2　[id:本文:スレ識別ID:作成日]

スレ識別IDでどのスレッドのレスか見分ける　テーブル1のidと同じかどうか

もし三次元が可能なら

テーブル1　 [[id]
.          [レス本文1,レス本文2,レス本文3,レス本文4.........]
.          [レス作成日,レス作成日,レス作成日,レス作成日,.....]
.          [本文,]
.          [タイトル,]
.          [作成日,]
.          [更新日,]]

という感じです
知りたい点
そもそも三次元の構造は可能か？
できるだけ一つのテーブルにまとめたほうがいいのか？
似たようなサイトの実際の例などがあれば

環境 使用しているもの
django
mySQL
win10

参考
https://q.hatena.ne.jp/1262940213
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12161983817
https://qiita.com/tadsan/items/adaade6b675ac344f373

Answer 1

Monazilla/develop - ５ちゃんねるwiki

ここに旧2ちゃんねるの仕様について書かれた文書があるのでこれを元にテーブル設計するのが良いと思います。datファイルとsubject.txtの仕様を理解すれば簡易な掲示板を作る参考になります。

• Monazilla/develop/dat - ５ちゃんねるwiki
• Monazilla/develop/subject.txt - ５ちゃんねるwiki

---

テーブル1　 [[id]

. [レス本文1,レス本文2,レス本文3,レス本文4.........]
. [レス作成日,レス作成日,レス作成日,レス作成日,.....]
. [本文,]
. [タイトル,]
. [作成日,]
. [更新日,]]

上記の1テーブルにまとめたケースではいくつかのデメリットがあります。

1. レコードのサイズが巨大になる。１０００レスまであるスレッドの場合、場合によっては１レコードが1MB超になることもあります。 (もしレプリケーションする場合)レプリケーション・ログも巨大になるのでNetwork I/O または Disk I/Oがボトルネックになりスレーブの遅延が発生しやすい。

　

1. 単一レスの検索・参照で不要なディスクI/Oが発生する　/ テーブルが分けれれていればインデックスを作って余計なレコードを読み込まずにアクセス出来ます。

最近は、AWSとかで性能の良いRDBMSを提供してくれているのでよっぽど巨大なシステムでも無い限りパフォーマンスの問題は起きにくくなってますが問題が起きてしまうと手遅れだったりするので、設計段階で問題を洗い出せるのが良いです。

Answer 2

テーブル1個（カテゴリまで設置するなら2個）で可能ではないでしょうか。

スレッドテーブルに「親ID」を持ち、「親IDがNULLならそのスレッドの1」と判断できます。スレッドにぶら下がるコメントにはその1のIDを親IDとして入れていく。レス番号は1から連番。

1000レス云々はアプリケーション側の制御です。
当該スレッドのコメント数1000に達したらコメント投稿フォームを出さない。
「これ以上書き込めません」のような文言を出す。

カテゴリを設置する場合はカテゴリマスタを用意。カテゴリIDをスレッドテーブルに。カテゴリ名をカテゴリマスタに。