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

編集履歴

回答編集履歴

15

BIGINTを減らす

2016/12/24 01:29

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -28,7 +28,7 @@
28
28
 
29
29
  ```sql
30
30
  CREATE TABLE users(
31
- `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
31
+ `id` INTEGER UNSIGNED PRIMARY KEY AUTO_INCREMENT,
32
32
  `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
33
33
  `created_at` DATETIME NOT NULL,
34
34
  `updated_at` DATETIME NOT NULL
@@ -36,7 +36,7 @@
36
36
 
37
37
  CREATE TABLE credentials(
38
38
  `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
39
- `user_id` BIGINT UNSIGNED NOT NULL,
39
+ `user_id` INTEGER UNSIGNED NOT NULL,
40
40
  `access_token` VARCHAR(60) NOT NULL UNIQUE,
41
41
  `access_token_secret` VARCHAR(60) NOT NULL,
42
42
  `screen_name` VARCHAR(20) NOT NULL,

14

AI設定ミス

2016/12/24 01:29

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -28,14 +28,14 @@
28
28
 
29
29
  ```sql
30
30
  CREATE TABLE users(
31
- `id` BIGINT UNSIGNED PRIMARY KEY,
31
+ `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
32
32
  `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
33
33
  `created_at` DATETIME NOT NULL,
34
34
  `updated_at` DATETIME NOT NULL
35
35
  );
36
36
 
37
37
  CREATE TABLE credentials(
38
- `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
38
+ `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
39
39
  `user_id` BIGINT UNSIGNED NOT NULL,
40
40
  `access_token` VARCHAR(60) NOT NULL UNIQUE,
41
41
  `access_token_secret` VARCHAR(60) NOT NULL,

13

access_tokenだけUNIQUEあり

2016/12/24 01:22

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -8,7 +8,7 @@
8
8
  ```sql
9
9
  CREATE TABLE users(
10
10
  `id` BIGINT UNSIGNED PRIMARY KEY,
11
- `access_token` VARCHAR(60) NOT NULL,
11
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
12
12
  `access_token_secret` VARCHAR(60) NOT NULL,
13
13
  `screen_name` VARCHAR(20) NOT NULL,
14
14
  `name` VARCHAR(25) NOT NULL,
@@ -37,7 +37,7 @@
37
37
  CREATE TABLE credentials(
38
38
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
39
39
  `user_id` BIGINT UNSIGNED NOT NULL,
40
- `access_token` VARCHAR(60) NOT NULL,
40
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
41
41
  `access_token_secret` VARCHAR(60) NOT NULL,
42
42
  `screen_name` VARCHAR(20) NOT NULL,
43
43
  `name` VARCHAR(25) NOT NULL,

12

UNIQUE解除

2016/12/24 01:05

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -8,9 +8,9 @@
8
8
  ```sql
9
9
  CREATE TABLE users(
10
10
  `id` BIGINT UNSIGNED PRIMARY KEY,
11
- `access_token` VARCHAR(60) NOT NULL UNIQUE ,
11
+ `access_token` VARCHAR(60) NOT NULL,
12
12
  `access_token_secret` VARCHAR(60) NOT NULL,
13
- `screen_name` VARCHAR(20) NOT NULL UNIQUE ,
13
+ `screen_name` VARCHAR(20) NOT NULL,
14
14
  `name` VARCHAR(25) NOT NULL,
15
15
  `description` VARCHAR(180) NOT NULL,
16
16
  `created_at` DATETIME NOT NULL,
@@ -18,6 +18,8 @@
18
18
  );
19
19
  ```
20
20
 
21
+ 知らない間にscreen_nameが変更され，それが別の人のものに入れ替わっている可能性があるので，あえてUNIQUE制約は外しました。
22
+
21
23
  > API Key の記録について
22
24
 
23
25
  最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。JOIN句を使えばクエリは1個に収まりますし。
@@ -35,9 +37,9 @@
35
37
  CREATE TABLE credentials(
36
38
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
37
39
  `user_id` BIGINT UNSIGNED NOT NULL,
38
- `access_token` VARCHAR(60) NOT NULL UNIQUE,
40
+ `access_token` VARCHAR(60) NOT NULL,
39
41
  `access_token_secret` VARCHAR(60) NOT NULL,
40
- `screen_name` VARCHAR(20) NOT NULL UNIQUE,
42
+ `screen_name` VARCHAR(20) NOT NULL,
41
43
  `name` VARCHAR(25) NOT NULL,
42
44
  `description` VARCHAR(180) NOT NULL,
43
45
  `created_at` DATETIME NOT NULL,

11

fix

2016/12/24 01:03

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -8,9 +8,9 @@
8
8
  ```sql
9
9
  CREATE TABLE users(
10
10
  `id` BIGINT UNSIGNED PRIMARY KEY,
11
- `access_token` VARCHAR(60) UNIQUE NOT NULL,
11
+ `access_token` VARCHAR(60) NOT NULL UNIQUE ,
12
12
  `access_token_secret` VARCHAR(60) NOT NULL,
13
- `screen_name` VARCHAR(20) UNIQUE NOT NULL,
13
+ `screen_name` VARCHAR(20) NOT NULL UNIQUE ,
14
14
  `name` VARCHAR(25) NOT NULL,
15
15
  `description` VARCHAR(180) NOT NULL,
16
16
  `created_at` DATETIME NOT NULL,

10

fix

2016/12/24 01:00

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -27,7 +27,7 @@
27
27
  ```sql
28
28
  CREATE TABLE users(
29
29
  `id` BIGINT UNSIGNED PRIMARY KEY,
30
- `main_access_token_id` NOT NULL,
30
+ `main_access_token_id` BIGINT UNSIGNED NOT NULL UNIQUE,
31
31
  `created_at` DATETIME NOT NULL,
32
32
  `updated_at` DATETIME NOT NULL
33
33
  );
@@ -35,9 +35,9 @@
35
35
  CREATE TABLE credentials(
36
36
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
37
37
  `user_id` BIGINT UNSIGNED NOT NULL,
38
- `access_token` VARCHAR(60) UNIQUE NOT NULL,
38
+ `access_token` VARCHAR(60) NOT NULL UNIQUE,
39
39
  `access_token_secret` VARCHAR(60) NOT NULL,
40
- `screen_name` VARCHAR(20) UNIQUE NOT NULL,
40
+ `screen_name` VARCHAR(20) NOT NULL UNIQUE,
41
41
  `name` VARCHAR(25) NOT NULL,
42
42
  `description` VARCHAR(180) NOT NULL,
43
43
  `created_at` DATETIME NOT NULL,

9

JOIN

2016/12/24 01:00

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -20,8 +20,10 @@
20
20
 
21
21
  > API Key の記録について
22
22
 
23
- 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
23
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。JOIN句を使えばクエリは1個に収まりますし。
24
24
 
25
+ それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
26
+
25
27
  ```sql
26
28
  CREATE TABLE users(
27
29
  `id` BIGINT UNSIGNED PRIMARY KEY,

8

a

2016/12/24 00:58

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -43,5 +43,5 @@
43
43
  );
44
44
  ```
45
45
 
46
- 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも可能です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
46
+ 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも非常に容易です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
47
47
 

7

redis

2016/12/24 00:57

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -20,7 +20,7 @@
20
20
 
21
21
  > API Key の記録について
22
22
 
23
- 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。
23
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。それこそこの程度でボトルネックになってしまうのであれば，（綿密な設計を行った上で）ストレージとしてMySQLの代わりにRedisなどを使うことを検討すべきだと思います。
24
24
 
25
25
  ```sql
26
26
  CREATE TABLE users(

6

NOT NULL

2016/12/24 00:56

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -33,7 +33,7 @@
33
33
  CREATE TABLE credentials(
34
34
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
35
35
  `user_id` BIGINT UNSIGNED NOT NULL,
36
- `access_token` VARCHAR(60) UNIQUE,
36
+ `access_token` VARCHAR(60) UNIQUE NOT NULL,
37
37
  `access_token_secret` VARCHAR(60) NOT NULL,
38
38
  `screen_name` VARCHAR(20) UNIQUE NOT NULL,
39
39
  `name` VARCHAR(25) NOT NULL,

5

追記

2016/12/24 00:54

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -33,7 +33,7 @@
33
33
  CREATE TABLE credentials(
34
34
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
35
35
  `user_id` BIGINT UNSIGNED NOT NULL,
36
- `access_token` VARCHAR(60) PRIMARY KEY,
36
+ `access_token` VARCHAR(60) UNIQUE,
37
37
  `access_token_secret` VARCHAR(60) NOT NULL,
38
38
  `screen_name` VARCHAR(20) UNIQUE NOT NULL,
39
39
  `name` VARCHAR(25) NOT NULL,
@@ -43,5 +43,5 @@
43
43
  );
44
44
  ```
45
45
 
46
- 主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
46
+ 例えばこのような設計にすれば，後からメインアカウントとして利用するトークンを変更することも可能です。但し，主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
47
47
 

4

credentials

2016/12/24 00:53

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -30,7 +30,7 @@
30
30
  `updated_at` DATETIME NOT NULL
31
31
  );
32
32
 
33
- CREATE TABLE accounts(
33
+ CREATE TABLE credentials(
34
34
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
35
35
  `user_id` BIGINT UNSIGNED NOT NULL,
36
36
  `access_token` VARCHAR(60) PRIMARY KEY,

3

変更

2016/12/24 00:51

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -15,7 +15,7 @@
15
15
  `description` VARCHAR(180) NOT NULL,
16
16
  `created_at` DATETIME NOT NULL,
17
17
  `updated_at` DATETIME NOT NULL
18
- )
18
+ );
19
19
  ```
20
20
 
21
21
  > API Key の記録について
@@ -28,9 +28,9 @@
28
28
  `main_access_token_id` NOT NULL,
29
29
  `created_at` DATETIME NOT NULL,
30
30
  `updated_at` DATETIME NOT NULL
31
- )
31
+ );
32
32
 
33
- CREATE TABLE tokens(
33
+ CREATE TABLE accounts(
34
34
  `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
35
35
  `user_id` BIGINT UNSIGNED NOT NULL,
36
36
  `access_token` VARCHAR(60) PRIMARY KEY,
@@ -40,7 +40,7 @@
40
40
  `description` VARCHAR(180) NOT NULL,
41
41
  `created_at` DATETIME NOT NULL,
42
42
  `updated_at` DATETIME NOT NULL
43
- )
43
+ );
44
44
  ```
45
45
 
46
46
  主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…

2

追記

2016/12/24 00:51

投稿

mpyw
mpyw

スコア5223

answer CHANGED
@@ -1,7 +1,9 @@
1
+ > 内部IDの記録について
2
+
1
3
  特に頭についている数字を意識したことは無かったんですが，あれユーザIDだったんですね…
2
4
  但し，この事実を前提として運用する必要は無いと思います。
3
5
 
4
- アクセストークンを使いたいときいちいち結合するの面倒じゃないですか？サイズも大したことないし，両方格納しておくのが正解に思えます。
6
+ （アクセストークンを使いたいときいちいち結合するの面倒じゃないですか？サイズも大したことないし，両方格納しておくのが正解に思えます）
5
7
 
6
8
  ```sql
7
9
  CREATE TABLE users(
@@ -14,4 +16,32 @@
14
16
  `created_at` DATETIME NOT NULL,
15
17
  `updated_at` DATETIME NOT NULL
16
18
  )
17
- ```
19
+ ```
20
+
21
+ > API Key の記録について
22
+
23
+ 最初からユーザとAPIキーが1対1で結びつかないことがわかっている場合，テーブルは分けるべきだと思います。よほど大規模なサービスでない限り，その程度の結合コストがボトルネックになることはありません。
24
+
25
+ ```sql
26
+ CREATE TABLE users(
27
+ `id` BIGINT UNSIGNED PRIMARY KEY,
28
+ `main_access_token_id` NOT NULL,
29
+ `created_at` DATETIME NOT NULL,
30
+ `updated_at` DATETIME NOT NULL
31
+ )
32
+
33
+ CREATE TABLE tokens(
34
+ `id` BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
35
+ `user_id` BIGINT UNSIGNED NOT NULL,
36
+ `access_token` VARCHAR(60) PRIMARY KEY,
37
+ `access_token_secret` VARCHAR(60) NOT NULL,
38
+ `screen_name` VARCHAR(20) UNIQUE NOT NULL,
39
+ `name` VARCHAR(25) NOT NULL,
40
+ `description` VARCHAR(180) NOT NULL,
41
+ `created_at` DATETIME NOT NULL,
42
+ `updated_at` DATETIME NOT NULL
43
+ )
44
+ ```
45
+
46
+ 主キーにVARCHARを使うとパフォーマンスが落ちてしまうのが難点ですね…
47
+

1

理由

2016/12/24 00:47

投稿

mpyw
mpyw

スコア5223

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