teratail
回答率
85.48%
質問するログイン新規登録
トップMySQLに関する質問Twitter API Access Token を 保存する MySQL構造についって

編集履歴

回答編集履歴

15

BIGINTを減らす

2016/12/24 01:29

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -58,7 +58,7 @@
58
58
 
59
59
  CREATE TABLE users(
60
60
 
61
- `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
61
+ `id` INTEGER UNSIGNED PRIMARY KEY AUTO_INCREMENT,
62
62
 
63
63
  `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
64
64
 
@@ -74,7 +74,7 @@
74
74
 
75
75
  `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
76
76
 
77
- `user_id` BIGINT UNSIGNED NOT NULL,
77
+ `user_id` INTEGER UNSIGNED NOT NULL,
78
78
 
79
79
  `access_token` VARCHAR(60) NOT NULL UNIQUE,
80
80
 

14

AI設定ミス

2016/12/24 01:29

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -58,7 +58,7 @@
58
58
 
59
59
  CREATE TABLE users(
60
60
 
61
- `id` BIGINT UNSIGNED PRIMARY KEY,
61
+ `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
62
62
 
63
63
  `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
64
64
 
@@ -72,7 +72,7 @@
72
72
 
73
73
  CREATE TABLE credentials(
74
74
 
75
- `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
75
+ `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
76
76
 
77
77
  `user_id` BIGINT UNSIGNED NOT NULL,
78
78
 

13

access_tokenだけUNIQUEあり

2016/12/24 01:22

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -18,7 +18,7 @@
18
18
 
19
19
  `id` BIGINT UNSIGNED PRIMARY KEY,
20
20
 
21
- `access_token` VARCHAR(60) NOT NULL,
21
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
22
22
 
23
23
  `access_token_secret` VARCHAR(60) NOT NULL,
24
24
 
@@ -76,7 +76,7 @@
76
76
 
77
77
  `user_id` BIGINT UNSIGNED NOT NULL,
78
78
 
79
- `access_token` VARCHAR(60) NOT NULL,
79
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
80
80
 
81
81
  `access_token_secret` VARCHAR(60) NOT NULL,
82
82
 

12

UNIQUE解除

2016/12/24 01:05

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -18,11 +18,11 @@
18
18
 
19
19
  `id` BIGINT UNSIGNED PRIMARY KEY,
20
20
 
21
- `access_token` VARCHAR(60) NOT NULL UNIQUE ,
21
+ `access_token` VARCHAR(60) NOT NULL,
22
22
 
23
23
  `access_token_secret` VARCHAR(60) NOT NULL,
24
24
 
25
- `screen_name` VARCHAR(20) NOT NULL UNIQUE ,
25
+ `screen_name` VARCHAR(20) NOT NULL,
26
26
 
27
27
  `name` VARCHAR(25) NOT NULL,
28
28
 
@@ -35,6 +35,10 @@
35
35
  );
36
36
 
37
37
  ```
38
+
39
+
40
+
41
+ 知らない間にscreen_nameが変更され，それが別の人のものに入れ替わっている可能性があるので，あえてUNIQUE制約は外しました。
38
42
 
39
43
 
40
44
 
@@ -72,11 +76,11 @@
72
76
 
73
77
  `user_id` BIGINT UNSIGNED NOT NULL,
74
78
 
75
- `access_token` VARCHAR(60) NOT NULL UNIQUE,
79
+ `access_token` VARCHAR(60) NOT NULL,
76
80
 
77
81
  `access_token_secret` VARCHAR(60) NOT NULL,
78
82
 
79
- `screen_name` VARCHAR(20) NOT NULL UNIQUE,
83
+ `screen_name` VARCHAR(20) NOT NULL,
80
84
 
81
85
  `name` VARCHAR(25) NOT NULL,
82
86
 

11

fix

2016/12/24 01:03

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -18,11 +18,11 @@
18
18
 
19
19
  `id` BIGINT UNSIGNED PRIMARY KEY,
20
20
 
21
- `access_token` VARCHAR(60) UNIQUE NOT NULL,
21
+ `access_token` VARCHAR(60) NOT NULL UNIQUE ,
22
22
 
23
23
  `access_token_secret` VARCHAR(60) NOT NULL,
24
24
 
25
- `screen_name` VARCHAR(20) UNIQUE NOT NULL,
25
+ `screen_name` VARCHAR(20) NOT NULL UNIQUE ,
26
26
 
27
27
  `name` VARCHAR(25) NOT NULL,
28
28
 

10

fix

2016/12/24 01:00

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -56,7 +56,7 @@
56
56
 
57
57
  `id` BIGINT UNSIGNED PRIMARY KEY,
58
58
 
59
- `main_access_token_id` NOT NULL,
59
+ `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
60
60
 
61
61
  `created_at` DATETIME NOT NULL,
62
62
 
@@ -72,11 +72,11 @@
72
72
 
73
73
  `user_id` BIGINT UNSIGNED NOT NULL,
74
74
 
75
- `access_token` VARCHAR(60) UNIQUE NOT NULL,
75
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
76
76
 
77
77
  `access_token_secret` VARCHAR(60) NOT NULL,
78
78
 
79
- `screen_name` VARCHAR(20) UNIQUE NOT NULL,
79
+ `screen_name` VARCHAR(20) NOT NULL UNIQUE,
80
80
 
81
81
  `name` VARCHAR(25) NOT NULL,
82
82
 

9

JOIN

2016/12/24 01:00

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -42,7 +42,11 @@
42
42
 
43
43
 
44
44
 
45
- 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
45
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。JOIN句を使えばクエリは1個に収まりますし。
46
+
47
+
48
+
49
+ それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
46
50
 
47
51
 
48
52
 

8

a

2016/12/24 00:58

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -88,7 +88,7 @@
88
88
 
89
89
 
90
90
 
91
- 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも可能です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
91
+ 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも非常に容易です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
92
92
 
93
93
 
94
94
 

7

redis

2016/12/24 00:57

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -42,7 +42,7 @@
42
42
 
43
43
 
44
44
 
45
- 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。
45
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
46
46
 
47
47
 
48
48
 

6

NOT NULL

2016/12/24 00:56

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -68,7 +68,7 @@
68
68
 
69
69
  `user_id` BIGINT UNSIGNED NOT NULL,
70
70
 
71
- `access_token` VARCHAR(60) UNIQUE,
71
+ `access_token` VARCHAR(60) UNIQUE NOT NULL,
72
72
 
73
73
  `access_token_secret` VARCHAR(60) NOT NULL,
74
74
 

5

追記

2016/12/24 00:54

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -68,7 +68,7 @@
68
68
 
69
69
  `user_id` BIGINT UNSIGNED NOT NULL,
70
70
 
71
- `access_token` VARCHAR(60) PRIMARY KEY,
71
+ `access_token` VARCHAR(60) UNIQUE,
72
72
 
73
73
  `access_token_secret` VARCHAR(60) NOT NULL,
74
74
 
@@ -88,7 +88,7 @@
88
88
 
89
89
 
90
90
 
91
- 主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
91
+ 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも可能です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
92
92
 
93
93
 
94
94
 

4

credentials

2016/12/24 00:53

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -62,7 +62,7 @@
62
62
 
63
63
 
64
64
 
65
- CREATE TABLE accounts(
65
+ CREATE TABLE credentials(
66
66
 
67
67
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
68
68
 

3

変更

2016/12/24 00:51

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -32,7 +32,7 @@
32
32
 
33
33
  `updated_at` DATETIME NOT NULL
34
34
 
35
- )
35
+ );
36
36
 
37
37
  ```
38
38
 
@@ -58,11 +58,11 @@
58
58
 
59
59
  `updated_at` DATETIME NOT NULL
60
60
 
61
- )
61
+ );
62
62
 
63
63
 
64
64
 
65
- CREATE TABLE tokens(
65
+ CREATE TABLE accounts(
66
66
 
67
67
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
68
68
 
@@ -82,7 +82,7 @@
82
82
 
83
83
  `updated_at` DATETIME NOT NULL
84
84
 
85
- )
85
+ );
86
86
 
87
87
  ```
88
88
 

2

追記

2016/12/24 00:51

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -1,10 +1,14 @@
1
+ > 内部IDの記録について
2
+
3
+
4
+
1
5
  特に頭についている数字を意識したことは無かったんですが，あれユーザIDだったんですね…
2
6
 
3
7
  但し，この事実を前提として運用する必要は無いと思います。
4
8
 
5
9
 
6
10
 
7
- アクセストークンを使いたいときいちいち結合するの面倒じゃないですか？サイズも大したことないし，両方格納しておくのが正解に思えます。
11
+ （アクセストークンを使いたいときいちいち結合するの面倒じゃないですか？サイズも大したことないし，両方格納しておくのが正解に思えます）
8
12
 
9
13
 
10
14
 
@@ -31,3 +35,61 @@
31
35
  )
32
36
 
33
37
  ```
38
+
39
+
40
+
41
+ > API Key の記録について
42
+
43
+
44
+
45
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。
46
+
47
+
48
+
49
+ ```sql
50
+
51
+ CREATE TABLE users(
52
+
53
+ `id` BIGINT UNSIGNED PRIMARY KEY,
54
+
55
+ `main_access_token_id` NOT NULL,
56
+
57
+ `created_at` DATETIME NOT NULL,
58
+
59
+ `updated_at` DATETIME NOT NULL
60
+
61
+ )
62
+
63
+
64
+
65
+ CREATE TABLE tokens(
66
+
67
+ `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
68
+
69
+ `user_id` BIGINT UNSIGNED NOT NULL,
70
+
71
+ `access_token` VARCHAR(60) PRIMARY KEY,
72
+
73
+ `access_token_secret` VARCHAR(60) NOT NULL,
74
+
75
+ `screen_name` VARCHAR(20) UNIQUE NOT NULL,
76
+
77
+ `name` VARCHAR(25) NOT NULL,
78
+
79
+ `description` VARCHAR(180) NOT NULL,
80
+
81
+ `created_at` DATETIME NOT NULL,
82
+
83
+ `updated_at` DATETIME NOT NULL
84
+
85
+ )
86
+
87
+ ```
88
+
89
+
90
+
91
+ 主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
92
+
93
+
94
+
95
+

1

理由

2016/12/24 00:47

投稿

mpyw
mpyw

スコア5223

test CHANGED
@@ -1,6 +1,10 @@
1
1
  特に頭についている数字を意識したことは無かったんですが，あれユーザIDだったんですね…
2
2
 
3
3
  但し，この事実を前提として運用する必要は無いと思います。
4
+
5
+
6
+
7
+ アクセストークンを使いたいときいちいち結合するの面倒じゃないですか？サイズも大したことないし，両方格納しておくのが正解に思えます。
4
8
 
5
9
 
6
10