はてなユーザ情報をDBに保存する場合のスキーマ設計

実用性に乏しいかもしれませんが、はてな認証APIから得られるはてなユーザの情報をDBに保存する場合、下記のようなテーブル構成をとる方法もあるかと考えています。

［ユーザ名］

カラム名	型	主キー	一意	参照
id	int	○
user_name	varchar(255)		○

［URL］

カラム名	型	主キー	一意	参照
id	int	○
url	varchar(255)		○

［ユーザ］

カラム名	型	主キー	一意	参照
id	int	○
user_name_id	int		○	［ユーザ名］.id
image_url_id	int			［URL］.id
thumbnail_url_id	int			［URL］.id

カラム名や型など超適当ですが、イメージということで。

普通は：

［ユーザ］

カラム名	型	主キー	一意	参照
id	int	○
user_name	varchar(255)		○
image_url	varchar(255)
thumbnail_url	varchar(255)

だと思うんですが、待てよ、と。これは：

［すしネタ好き嫌い］

カラム名	型	主キー	一意	参照
id	int	○
person	varchar(255)		○
likes	varchar(255)
dislikes	varchar(255)

という設計と同じではないかと。この場合「すしネタ」テーブルを独立させたほうがええんちゃうかと。

ま、それこそ好き嫌いかもしれませんが、「すしネタ」テーブルを独立させるような感覚で「URL」テーブルを独立させても良いのではないでしょうか。

この考えを突き詰めると、文字列は「主キー＋文字列」のテーブルに、数値は「主キー＋数値」のテーブルに、タイムスタンプは「主キー＋タイムスタンプ」のテーブルに、それぞれ格納されることになります。

『プレファクタリング―リファクタリング軽減のための新設計』という本には「ほとんどのStringは、単なるString以上のものである」と書かれていますが、まさにその通りで、「image_url」や「thumbnail_url」は「URL型」と考えられますし（URLをValidateする場面を考えてみてください）、「likes」や「dislikes」は「すしネタ型」とみなせます。

「URLテーブル」や「すしネタテーブル」を独立させることには、これら「URL型」や「すしネタ型」と1対1で結びつく、というメリットもあるのではないでしょうか。フレームワーク化しやすいとか。

なお（主キー以外に）複数のカラムを持つテーブルは、外部キーだけを持つことになります。この点は羽生章洋さんのいうABDに近い気がして、気に入っています。