回答編集履歴
5
追記２
test
CHANGED
|
@@ -144,8 +144,20 @@
|
|
|
144
144
|
|
|
145
145
|
|
|
146
146
|
|
|
147
|
-
###追記
|
|
147
|
+
###追記1
|
|
148
148
|
|
|
149
149
|
UNIQUEインデックス更新のパフォーマンス悪化のみ防ぎたい場合は、
|
|
150
150
|
|
|
151
151
|
管理テーブル、ランキングテーブルの二段階構成だけでも効果は見込めるかも
|
|
152
|
+
|
|
153
|
+
|
|
154
|
+
|
|
155
|
+
###追記2
|
|
156
|
+
|
|
157
|
+
今さら気づいたけど記事IDの精度は255桁なんですね。
|
|
158
|
+
|
|
159
|
+
IDで255桁ってあんまり聞いたことないかな･･･。
|
|
160
|
+
|
|
161
|
+
このIDの桁数を短くすることが可能でれば、
|
|
162
|
+
|
|
163
|
+
そうした方がパフォーマンス的にも良い気がします。
|
4
表記追加
test
CHANGED
|
@@ -10,11 +10,11 @@
|
|
|
10
10
|
|
|
11
11
|
リソースが許すのであればもう一段階テーブル分割するというのも一つの手かなと考えてます。
|
|
12
12
|
|
|
13
|
-
イメージとしてはスーパタイプ・サブタイプ
|
|
13
|
+
イメージとしてはスーパタイプ・サブタイプっぽい考え方にはなりますが・・・
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
- ランキング管理
|
|
17
|
+
- ランキング管理(スーパタイプっぽい何か)
|
|
18
18
|
|
|
19
19
|
```SQL
|
|
20
20
|
|
|
@@ -24,7 +24,7 @@
|
|
|
24
24
|
|
|
25
25
|
`category_id` INT(10) NOT NULL, # カテゴリID
|
|
26
26
|
|
|
27
|
-
`created_at` datetime NOT NULL, # ランキングが一括更新なら作成日、更新日はこっちだけでよい希ガス
|
|
27
|
+
`created_at` datetime NOT NULL, # ランキングが一括更新であるなら作成日、更新日はこっちだけでよい希ガス
|
|
28
28
|
|
|
29
29
|
`updated_at` datetime NOT NULL,
|
|
30
30
|
|
|
@@ -38,7 +38,7 @@
|
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
41
|
-
- カテゴリ別ランキング(「すべて」を除外したランキング)
|
|
41
|
+
- カテゴリ別ランキング(「すべて」を除外したランキング)(サブタイプ)
|
|
42
42
|
|
|
43
43
|
```SQL
|
|
44
44
|
|
|
@@ -62,7 +62,7 @@
|
|
|
62
62
|
|
|
63
63
|
|
|
64
64
|
|
|
65
|
-
- 全カテゴリランキング(「すべて」のみのランキングを格納)
|
|
65
|
+
- 全カテゴリランキング(「すべて」のみのランキングを格納)(サブタイプ)
|
|
66
66
|
|
|
67
67
|
```SQL
|
|
68
68
|
|
3
追記
test
CHANGED
|
@@ -143,3 +143,9 @@
|
|
|
143
143
|
[mysqlのint(11)のカッコ内の数値の意味](http://dbinfo.sakura.ne.jp/?contents_id=102)
|
|
144
144
|
|
|
145
145
|
|
|
146
|
+
|
|
147
|
+
###追記
|
|
148
|
+
|
|
149
|
+
UNIQUEインデックス更新のパフォーマンス悪化のみ防ぎたい場合は、
|
|
150
|
+
|
|
151
|
+
管理テーブル、ランキングテーブルの二段階構成だけでも効果は見込めるかも
|
2
主キー制約定義ミスってた・・・
test
CHANGED
|
@@ -48,9 +48,11 @@
|
|
|
48
48
|
|
|
49
49
|
`article_id` char(255) NOT NULL,
|
|
50
50
|
|
|
51
|
+
`category_id` INT(10) NOT NULL,
|
|
52
|
+
|
|
51
53
|
`ranking` INT(10) DEFAULT NULL,
|
|
52
54
|
|
|
53
|
-
PRIMARY KEY(rank_id)
|
|
55
|
+
PRIMARY KEY(rank_id, article_id)
|
|
54
56
|
|
|
55
57
|
)
|
|
56
58
|
|
|
@@ -72,7 +74,7 @@
|
|
|
72
74
|
|
|
73
75
|
`ranking` INT(10) DEFAULT NULL,
|
|
74
76
|
|
|
75
|
-
PRIMARY KEY(rank_id)
|
|
77
|
+
PRIMARY KEY(rank_id, article_id)
|
|
76
78
|
|
|
77
79
|
)
|
|
78
80
|
|
|
@@ -124,6 +126,8 @@
|
|
|
124
126
|
|
|
125
127
|
後々のためには入れたほうがいいかもです(管理テーブルとのカテゴリIDの二重持ちにはなりますが）
|
|
126
128
|
|
|
129
|
+
**※むしろ管理情報の主キーと結合して主キーに対する索引一意スキャンにした方が速度が出そう**なので直しときます。
|
|
130
|
+
|
|
127
131
|
|
|
128
132
|
|
|
129
133
|
あくまでもご参考程度までに。
|
1
コード変更
test
CHANGED
|
@@ -20,9 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
CREATE TABLE `ランキング管理` (
|
|
22
22
|
|
|
23
|
-
`rank_id` INT(10) UNSIGNED NOT NULL, # 管理用ID
|
|
23
|
+
`rank_id` INT(10) UNSIGNED NOT NULL, # 管理用ID(カテゴリ別、全カテゴリで同一IDで)
|
|
24
|
-
|
|
25
|
-
`rank_kind` char(1) NOT NULL, # 「カテゴリ別」 or 「すべて」を表す区分値(カテゴリIDからでも紐付くテーブルは判断可能だけど念のため)
|
|
26
24
|
|
|
27
25
|
`category_id` INT(10) NOT NULL, # カテゴリID
|
|
28
26
|
|
|
@@ -30,7 +28,7 @@
|
|
|
30
28
|
|
|
31
29
|
`updated_at` datetime NOT NULL,
|
|
32
30
|
|
|
33
|
-
PRIMARY KEY(rank_id, r
|
|
31
|
+
PRIMARY KEY(rank_id, category_id),
|
|
34
32
|
|
|
35
33
|
UNIQUE(category_id, created_at) # 検索条件で使われそうだから念のためINDEXを張る
|
|
36
34
|
|
|
@@ -139,3 +137,5 @@
|
|
|
139
137
|
NOT FILLオプションなどを指定しない限りはカッコ内に11を指定する意味はなさそうです。
|
|
140
138
|
|
|
141
139
|
[mysqlのint(11)のカッコ内の数値の意味](http://dbinfo.sakura.ne.jp/?contents_id=102)
|
|
140
|
+
|
|
141
|
+
|