回答編集履歴

3

補足

2017/01/13 09:18

投稿

popobot
popobot

スコア6586

test CHANGED
@@ -22,8 +22,6 @@
22
22
 
23
23
  もしくは、もし今後管理者と一般ユーザ両方に紐付ける必要がテーブルが増えるなら、authorsという、adminsとusers両方を管理する中間テーブルを作ってauthorsとarticlesを関連付けるのもありかもしれません。
24
24
 
25
-
26
-
27
25
  ```
28
26
 
29
27
  authors (id, admin_id, user_id)
@@ -33,3 +31,5 @@
33
31
  users.id ⇔ authors.user_id authors.id ⇔ articles.author_id
34
32
 
35
33
  ```
34
+
35
+ ※adminsとusersの基底クラスauthorsみたいなイメージ

2

補足

2017/01/13 09:18

投稿

popobot
popobot

スコア6586

test CHANGED
@@ -13,3 +13,23 @@
13
13
  表示のときには、管理者か一般ユーザか存在する方を出せばよいだけですし。
14
14
 
15
15
  唯一のデメリットはNOT NULL制約が使えないことぐらいかと(アプリ側でカバー)
16
+
17
+
18
+
19
+ ----
20
+
21
+
22
+
23
+ もしくは、もし今後管理者と一般ユーザ両方に紐付ける必要がテーブルが増えるなら、authorsという、adminsとusers両方を管理する中間テーブルを作ってauthorsとarticlesを関連付けるのもありかもしれません。
24
+
25
+
26
+
27
+ ```
28
+
29
+ authors (id, admin_id, user_id)
30
+
31
+ admins.id ⇔ authors.admin_id authors.id ⇔ articles.author_id
32
+
33
+ users.id ⇔ authors.user_id authors.id ⇔ articles.author_id
34
+
35
+ ```

1

誤字

2017/01/13 09:17

投稿

popobot
popobot

スコア6586

test CHANGED
@@ -1,4 +1,4 @@
1
- 自分なら以下の実装にしますね。なんどかこういう実装をしたことがあります。
1
+ 自分なら以下の実装にしますね。何度かこういう実装をしたことがあります。
2
2
 
3
3
  ※もしくはadminsとusersのテーブルを統合するか...(影響範囲しだいですが)
4
4