回答編集履歴
1
追記を受けての追記
test
CHANGED
@@ -9,3 +9,49 @@
|
|
9
9
|
|
10
10
|
|
11
11
|
「何を実現したいのか」が明確になればより「よくある」アプローチについて回答を得られるかと思いますよ。
|
12
|
+
|
13
|
+
|
14
|
+
|
15
|
+
|
16
|
+
|
17
|
+
**以下追記
|
18
|
+
|
19
|
+
> 現在開発しているアプリがツイッターのように1つのタイムラインで全員が会話するものではなく、2chの掲示板のように複数あるコミュニティ(このコミュニティはユーザーが作成することができる)の中で、タイムラインが存在するようなものなんですが、そういった場合1つのテーブルの中ですべてのコミュニティのタイムライン情報が管理されているのでしょうか。
|
20
|
+
|
21
|
+
> 直感的ではありますが、コミュニティごとのタイムラインを管理するようなテーブルがあったほうがスムーズのような気もするのですが。
|
22
|
+
|
23
|
+
> いかがでしょうか。
|
24
|
+
|
25
|
+
|
26
|
+
|
27
|
+
そういった場合、RDBMSで実装するなら
|
28
|
+
|
29
|
+
- コミュニティテーブル
|
30
|
+
|
31
|
+
コミュニティの情報を保存する
|
32
|
+
|
33
|
+
- タイムラインテーブル
|
34
|
+
|
35
|
+
コミュニティIDとタイムラインそのもの(タイムライン作成日時やタイムライン名)を保存する
|
36
|
+
|
37
|
+
- タイムライン参加者管理テーブル
|
38
|
+
|
39
|
+
タイムラインへの参加/退席をレコードで管理
|
40
|
+
|
41
|
+
- タイムラインへの発言テーブル
|
42
|
+
|
43
|
+
タイムラインへの発言をレコードで管理
|
44
|
+
|
45
|
+
という様な形で実装するのが定石です。
|
46
|
+
|
47
|
+
各テーブルについて外部キーとインデックスが適切に紐づいていれば、
|
48
|
+
|
49
|
+
「このタイムラインの発言一覧を取得する」といった操作がRDBMSが得意な方法で実装可能です。
|
50
|
+
|
51
|
+
|
52
|
+
|
53
|
+
また、こうしないとコミュニティやタイムラインをまたいだ検索や統計を取ることが出来なくなったりと拡張性がほぼ無くなります。
|
54
|
+
|
55
|
+
|
56
|
+
|
57
|
+
どうしてもテーブルを分けたいのであれば、RDBMSでは無くてNoSQLやファイルベース(2chのdatのイメージ)で実装してしまった方が素直です。
|