teratail header banner
teratail header banner
質問するログイン新規登録

回答編集履歴

1

追記を受けての追記

2015/11/30 04:49

投稿

tanat
tanat

スコア18778

answer CHANGED
@@ -3,4 +3,27 @@
3
3
  RDBMSはテーブルというデータ定義の下にレコードというデータそのものをぶら下げていき、原則として同じ定義(役割として同じ)データは同じテーブルに格納することで集計や検索、更新の機能と利便性を確保するという性質を持つ仕組みであるためです。
4
4
  *極端にレコードが多い、年次/月次ごとにテーブルを分けたいなど、場合によっては必要な場合もあるとは思います。
5
5
 
6
- 「何を実現したいのか」が明確になればより「よくある」アプローチについて回答を得られるかと思いますよ。
6
+ 「何を実現したいのか」が明確になればより「よくある」アプローチについて回答を得られるかと思いますよ。
7
+
8
+
9
+ **以下追記
10
+ > 現在開発しているアプリがツイッターのように1つのタイムラインで全員が会話するものではなく、2chの掲示板のように複数あるコミュニティ(このコミュニティはユーザーが作成することができる)の中で、タイムラインが存在するようなものなんですが、そういった場合1つのテーブルの中ですべてのコミュニティのタイムライン情報が管理されているのでしょうか。
11
+ > 直感的ではありますが、コミュニティごとのタイムラインを管理するようなテーブルがあったほうがスムーズのような気もするのですが。
12
+ > いかがでしょうか。
13
+
14
+ そういった場合、RDBMSで実装するなら
15
+ - コミュニティテーブル
16
+ コミュニティの情報を保存する
17
+ - タイムラインテーブル
18
+ コミュニティIDとタイムラインそのもの(タイムライン作成日時やタイムライン名)を保存する
19
+ - タイムライン参加者管理テーブル
20
+ タイムラインへの参加/退席をレコードで管理
21
+ - タイムラインへの発言テーブル
22
+ タイムラインへの発言をレコードで管理
23
+ という様な形で実装するのが定石です。
24
+ 各テーブルについて外部キーとインデックスが適切に紐づいていれば、
25
+ 「このタイムラインの発言一覧を取得する」といった操作がRDBMSが得意な方法で実装可能です。
26
+
27
+ また、こうしないとコミュニティやタイムラインをまたいだ検索や統計を取ることが出来なくなったりと拡張性がほぼ無くなります。
28
+
29
+ どうしてもテーブルを分けたいのであれば、RDBMSでは無くてNoSQLやファイルベース(2chのdatのイメージ)で実装してしまった方が素直です。