回答編集履歴
5
蛇足
answer
CHANGED
|
@@ -118,4 +118,5 @@
|
|
|
118
118
|
データベースによってはカラムを**配列型**として定義できるとものもありますが、
|
|
119
119
|
ベンダ依存となるのでこれを利用するのもあまりオススメできません。
|
|
120
120
|
なので動的にパラメタが変化する場合は、
|
|
121
|
-
パラメタを管理するテーブルを作るのが無難な気がします。
|
|
121
|
+
パラメタを管理するテーブルを作るのが無難な気がします。
|
|
122
|
+
(俗に言う「マルチカラムアトリビュート」対策です)
|
4
追記
answer
CHANGED
|
@@ -105,4 +105,17 @@
|
|
|
105
105
|
AND 会員.会員タイプ = '1'
|
|
106
106
|
WHERE
|
|
107
107
|
一時会員.有効期限 < 現在日
|
|
108
|
-
```
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
###追記
|
|
111
|
+
パラメータが動的に変わるという部分を見逃してました^^;
|
|
112
|
+
|
|
113
|
+
データベースのテーブルでは、
|
|
114
|
+
カラム(各種パラメタ値)を動的に増やすのはNGですし、
|
|
115
|
+
１つのカラムにはパラメタを連結して登録するのもオススメはできません。
|
|
116
|
+
(アンチパターンに記載されるレベルには推奨されてません。)
|
|
117
|
+
|
|
118
|
+
データベースによってはカラムを**配列型**として定義できるとものもありますが、
|
|
119
|
+
ベンダ依存となるのでこれを利用するのもあまりオススメできません。
|
|
120
|
+
なので動的にパラメタが変化する場合は、
|
|
121
|
+
パラメタを管理するテーブルを作るのが無難な気がします。
|
3
誤字脱字の修正
answer
CHANGED
|
@@ -36,7 +36,7 @@
|
|
|
36
36
|
|
|
37
37
|
このように分けると、
|
|
38
38
|
データベース特有の問題である**更新時不整合**などの問題も抑制できますので、
|
|
39
|
-
そういう意味でも分けると良いかな
|
|
39
|
+
そういう意味でも分けると良いかなと思います。
|
|
40
40
|
(**「正規化 更新時不整合」**などで調べるとより詳しい情報が得られると思います。)
|
|
41
41
|
|
|
42
42
|
ちなみに上のようにテーブルを分けた場合、父親が同一の人物を得たい時は、下記のようなクエリで取得できます。
|
2
見栄えの修正など
answer
CHANGED
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
提示されたサンプルからは、
|
|
2
|
-
共通性・継承性という点がしっくりきませんでしたが
|
|
2
|
+
共通性・継承性という点がしっくりきませんでしたが、
|
|
3
3
|
上記のような例では関係(リレーション)自体をテーブル化するのがよくあるパターンかなと思います。
|
|
4
4
|
|
|
5
5
|
###関係のテーブル化
|
|
@@ -11,8 +11,8 @@
|
|
|
11
11
|
|
|
12
12
|
以下はそれぞれのモデル例です。
|
|
13
13
|
|
|
14
|
-
```
|
|
14
|
+
```
|
|
15
|
-
個人情報
|
|
15
|
+
個人情報
|
|
16
16
|
ID (主キー)
|
|
17
17
|
名前
|
|
18
18
|
年齢
|
|
@@ -20,16 +20,16 @@
|
|
|
20
20
|
```
|
|
21
21
|
|
|
22
22
|
```SQL
|
|
23
|
-
両親
|
|
23
|
+
両親
|
|
24
24
|
ID(主キー)
|
|
25
25
|
父親(個人情報.IDへの外部キー)
|
|
26
26
|
母親(個人情報.IDへの外部キー)
|
|
27
27
|
一意キー(父親、母親)
|
|
28
28
|
```
|
|
29
29
|
|
|
30
|
-
```
|
|
30
|
+
```
|
|
31
|
-
友人(関連エンティティ)
|
|
32
|
-
|
|
31
|
+
友人
|
|
32
|
+
個人ID(個人情報.IDへの外部キー)
|
|
33
33
|
友人(個人情報.IDへの外部キー)
|
|
34
34
|
主キー(個人ID, 友人)
|
|
35
35
|
```
|
|
@@ -66,20 +66,23 @@
|
|
|
66
66
|
(サンプルの構成は単純なのであまり分けるメリット感じられないかもしれませんが)
|
|
67
67
|
|
|
68
68
|
```SQL
|
|
69
|
-
会員
|
|
69
|
+
-- 会員タイプ全てに共通する属性はここで定義
|
|
70
|
+
会員
|
|
70
71
|
会員ID(主キー)
|
|
71
72
|
会員タイプ -- 「1:一時」「2:特別」
|
|
72
73
|
会員登録日
|
|
73
74
|
```
|
|
74
75
|
|
|
75
76
|
```SQL
|
|
76
|
-
一時会員
|
|
77
|
+
-- 一時会員固有の属性を定義
|
|
78
|
+
一時会員
|
|
77
79
|
会員ID(主キー)
|
|
78
80
|
有効期限
|
|
79
81
|
```
|
|
80
82
|
|
|
81
83
|
```SQL
|
|
82
|
-
特別会員
|
|
84
|
+
-- 特別会員固有の属性を定義
|
|
85
|
+
特別会員
|
|
83
86
|
会員ID(主キー)
|
|
84
87
|
付与ポイント残
|
|
85
88
|
最終ポイント利用日
|
1
テーブル例修正
answer
CHANGED
|
@@ -24,14 +24,14 @@
|
|
|
24
24
|
ID(主キー)
|
|
25
25
|
父親(個人情報.IDへの外部キー)
|
|
26
26
|
母親(個人情報.IDへの外部キー)
|
|
27
|
-
一意
|
|
27
|
+
一意キー(父親、母親)
|
|
28
28
|
```
|
|
29
29
|
|
|
30
30
|
```SQL
|
|
31
31
|
友人(関連エンティティ)
|
|
32
32
|
個人ID
|
|
33
33
|
友人(個人情報.IDへの外部キー)
|
|
34
|
-
主キー
|
|
34
|
+
主キー(個人ID, 友人)
|
|
35
35
|
```
|
|
36
36
|
|
|
37
37
|
このように分けると、
|