回答編集履歴
3
補足
answer
CHANGED
|
@@ -10,9 +10,9 @@
|
|
|
10
10
|
----
|
|
11
11
|
|
|
12
12
|
もしくは、もし今後管理者と一般ユーザ両方に紐付ける必要がテーブルが増えるなら、authorsという、adminsとusers両方を管理する中間テーブルを作ってauthorsとarticlesを関連付けるのもありかもしれません。
|
|
13
|
-
|
|
14
13
|
```
|
|
15
14
|
authors (id, admin_id, user_id)
|
|
16
15
|
admins.id ⇔ authors.admin_id authors.id ⇔ articles.author_id
|
|
17
16
|
users.id ⇔ authors.user_id authors.id ⇔ articles.author_id
|
|
18
|
-
```
|
|
17
|
+
```
|
|
18
|
+
※adminsとusersの基底クラスauthorsみたいなイメージ
|
2
補足
answer
CHANGED
|
@@ -5,4 +5,14 @@
|
|
|
5
5
|
|
|
6
6
|
JOINもシンプルですし、構造上わかりやすいので、そんなに悪いとは思いませんけどね。
|
|
7
7
|
表示のときには、管理者か一般ユーザか存在する方を出せばよいだけですし。
|
|
8
|
-
唯一のデメリットはNOT NULL制約が使えないことぐらいかと（アプリ側でカバー）
|
|
8
|
+
唯一のデメリットはNOT NULL制約が使えないことぐらいかと（アプリ側でカバー）
|
|
9
|
+
|
|
10
|
+
----
|
|
11
|
+
|
|
12
|
+
もしくは、もし今後管理者と一般ユーザ両方に紐付ける必要がテーブルが増えるなら、authorsという、adminsとusers両方を管理する中間テーブルを作ってauthorsとarticlesを関連付けるのもありかもしれません。
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
authors (id, admin_id, user_id)
|
|
16
|
+
admins.id ⇔ authors.admin_id authors.id ⇔ articles.author_id
|
|
17
|
+
users.id ⇔ authors.user_id authors.id ⇔ articles.author_id
|
|
18
|
+
```
|
1
誤字
answer
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
自分なら以下の実装にしますね。
|
|
1
|
+
自分なら以下の実装にしますね。何度かこういう実装をしたことがあります。
|
|
2
2
|
※もしくはadminsとusersのテーブルを統合するか...（影響範囲しだいですが）
|
|
3
3
|
|
|
4
4
|
> 最小限の変更で実装してしまうなら articles.admin_id, articles.user_id というカラムを用意し、管理者が書いた記事には admin_id = 管理者ID, user_id = null にし、ユーザーが書いた記事には user_id = ユーザーID, admin_id = null にするという手段があるかと思いますが綺麗とは言えません。
|