Re: CakePHP日記 #006 ディレクトリ構成とDB設計

こんにちは。青い人です。CakePHPでSNSっぽいものを作ろうとして挫折するまでのコーディング日記 | i d e a * i d e aが更新されました。#006にツッコミをいれていきます。

ディレクトリ構成、ユーザーディレクトリ直下はちょっと...?

変更後のレイアウトはこんな感じ。

/home/webadmin/
/app
/webroot ← DocumentRootに設定。
/cake
/vendors
.htaccess
index.php
VERSION.txt

/home/webadmin/ 直下というのが気にかかります。もしwebadminがあるユーザーの(この場合はおそらくwebadminユーザーの)ホームディレクトリだとしたら、/home/webadmin/sns/ の下に配置したほうがよいでしょう。

DB設計、主にインデックスの追加

SNSアプリとのことで、ユーザー・日記・友人情報テーブルのスキーマが上がってきました。必須ではありませんが、あとあとのことを考えるとインデックスぐらいは作っておいたほうがよいと思います。

# Users（ユーザー）

まずはUsers。最小限な感じです。写真のアップ、ログイン時間とかはあとで考えよう。パスワードもとりあえず暗号化せずにいっときます。

DROP TABLE IF EXISTS users;
CREATE TABLE users (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(50),
email VARCHAR(255),
pwd VARCHAR(255),
profile TEXT,
created DATETIME DEFAULT NULL,
modified DATETIME DEFAULT NULL
);
INSERT INTO users (name,email,pwd) values ('taguchi','taguchi@foo.com','taguchipwd');
INSERT INTO users (name,email,pwd) values ('akiyan','akiyan@foo.com','akiyanpwd');

一概には言えませんが、emailをログイン名として認証するのであればbinary属性をつけておいた方がよいかもしれません。binary属性が無いと、大文字小文字が違ってもヒットしてしまうので、正確に認証するためにはヒット後にphpで再判定する必要があります。

また、emailが一意であればUNIQUE INDEXもつけるべきでしょう。データの2重登録を防止できます。

フィールド名は申し分無いですね。Cakeの命名規則ではプライマリキーは必ず「id」で、作成日と更新日は「created」「modified」です。ちなみにcreatedとmodifiedは作らなくても動作します。

# Posts （← 日記。Diariesより語感がいいのでこちらに）

ユーザーが書く日記。日記ごとにオーナーがいる感じで。

DROP TABLE IF EXISTS posts;
CREATE TABLE posts (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id INT UNSIGNED,
title TEXT,
body TEXT,
created DATETIME DEFAULT NULL,
modified DATETIME DEFAULT NULL
);

user_id・createdの複合indexを作るとよいです。きっと「ユーザーIDで絞り込んで」「作成順に並び替える」ことになるので。

ちなみにuser_idはusersテーブルへの参照キーです。Cakeでの参照キーの命名規則は「モデル名_id」なので、ばっちりです。

# Friends （友達関係のJoinテーブル）

ここは誰が誰の友達かを表すテーブル。ちょっとズルをして青い人に聞きながらつくってみました。

DROP TABLE IF EXISTS friends;
CREATE TABLE friends (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
user_id INT UNSIGNED,
friend_user_id INT UNSIGNED,
status INT UNSIGNED,
created DATETIME DEFAULT NULL,
modified DATETIME DEFAULT NULL
);

まずuser_id・friend_idを複合キーでUNIQUE INDEXを作って2重登録を防止します。

次にuser_id・status・modifiedの複合indexも作っておきましょう。「ユーザーIDで絞り込んで」「ステータスで絞り込んで」「承認順(更新順)に並び替える」ことになるからです。（statusには承認待ちかどうかなどが入ります）

承認順は無くてもuser_id・statusでの絞り込みはあるので、この順序の複合indexであれば流用されます。

今回は以上です。