- id番号はユーザーの通し番号であり、ユニーク制約とオートインクリメントが設定
- 会員の登録情報に変更があった場合、このID番号の会員情報を変更するようになっている
まず、この2点はセオリーとして設計が間違っています。
QAサイトでよくある質問ではありますが、「IDを変更できる」ようにしたいという要件は、「特定のあるユーザー」が削除された時に、IDが欠番になってしまい、「気持ち悪い」という曖昧な感覚の問題であるように推測します。
なぜ AutoIncrement の値を変えてはいけないのか
例えば、以下のような User テーブル を想定します。
sql
1CREATE TABLE `User` (
2 `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'AI',
3 `user_name` varchar(64) DEFAULT NULL COMMENT '氏名',
4 PRIMARY KEY (`id`)
5) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
このテーブルが、他のテーブルと一切関連がなく、完全に独立したものであれば、id
を変更しても、ユニークであれば、問題はないでしょう。
ただし、このユーザーテーブルが通常のシステムにおいて、他のテーブルとはなんらかの関連を持っているものです。
[親]Company(会社)- [子]User の関係であるとか、[親]User - [子]Article(記事)といった具合です。
特に User が 親 である場合には、大変なことが起きます。
【User】
【Article】
| ID | article | create_user_id |
|----------:|:-----------|
| 1 | 記事1 | 2 |
| 2 | 記事2 | 1 |
| 3 | 記事3 | 3 |
User と Article がこのように関連づいています。
ここで、ID: 2 の武田さんの番号を変更する場合、Article の ID:1 のレコードの create_user_id も変更しないといけません。
ほとんどのシステムにおいては、一つのテーブルが他の多くのテーブルに関連づいているため、Article のみならず、数十というテーブルのデータを変更する必要すら出てきてしまいます。
代替案
どうしても「見た目」の問題として、「欠番があることが嫌だ」というのであれば、autoincrement を設定したIDをUIに表示するのではなく、表示用のID を別に設定することが望ましいです。
例えばこんな感じです。
sql
1CREATE TABLE `User` (
2 `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'AI',
3 `display_id` int(11) DEFAULT NULL COMMENT '表示用ユーザーID',
4 `user_name` varchar(64) DEFAULT NULL COMMENT '氏名',
5 PRIMARY KEY (`id`),
6 UNIQUE KEY `display_id` (`display_id`)
7) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/08/13 08:01
退会済みユーザー
2018/08/13 08:18 編集
2018/08/17 13:50