フォロー、フォロワー情報を保存するテーブルの作成
SNSサイトでは、よくユーザをフォローする機能をつけると思う。それに関するテーブルについての考察をのせる。
自分が思いついた最良のテーブルは、
CREATE TABLE follow_user
(
id INT(11) NOT NULL AUTO_INCREMENT,
uid1 INT(11) NOT NULL,
uid2 INT(11) NOT NULL,
PRIMARY KEY (id),
UNIQUE (uid1,uid2)
)
| id |
uid1 |
uid2 |
| 1 |
3 |
7 |
| 2 |
4 |
7 |
| 3 |
6 |
7 |
| ... |
|
|
| 5000 |
70 |
90 |
ここでは、uid1がフォローしているユーザのidでuid2がフォローされているユーザのidだとする。
ひとりのユーザは何人ものユーザをフォローできるので、uid1を主キーとすることはできない。また、フォローされる数もたくさんあるので,uid2を主キーとすることもできない。
主キーを貼ることができれば、データ量が増えてもB-Tree構造のお陰で決まった計算量で検索することができる。フォロー、フォロワー情報は参照される回数が多いので、どちらかのキーを主キーにできるのがベスト。
いくら考えてもその方法は、見つけられなかったので、uid1とuid2にユニークキーを貼ることで、参照性能を向上させる。
InnoDBでは、主キー以外のインデクス(クラスタインデックス)をセカンダリインデックスと呼ぶ。セカンダリインデックスを貼ると、それを検索するためのB-Treeが作成される。セカンダリインデックスのリーフノードには主キーが保存されいる。そのため、セカンダリインデックスで検索をかけた場合、主キーの検索をしてから、その主キーを使って目的のレコードの情報を検索することになる。
InnoDBの場合、明示的に主キーがを貼っていない場合は、勝手に主キーを貼ってくれる。というより、主キーがないとデータ構造が成り立たないので、勝手に主キーの代わりを見つけるか作ることになっている。
NOT NULLでユニークなキーがある場合はそれを、それに該当するものがない場合は、ROWIDを主キーとする。
勝手に作られるなら、こっちで作っておいた方があとあとの操作がやりやすそうなので明示的にidという主キーを作成してある。ちなみに、このような用途のキーをサロゲートキーという。
最終更新：2012年12月02日 16:54
