#3 DB設計がキモだと思う

DB設計がシステムのキモだと思う。システムは、データの表現（DB）と、見せ方（フロント）と動かし方（バックエンド）があると思うけど、結局データがクソだと全部クソだよねと思う

なんでかっていうとシステム、というか全体がわかってないとデータ表現できないから。PHPずっとやってきたし、PHPのことは愛しているし、初心者向けの解説とかたくさん書いてきたけども…
プログラミングの力だけ学んでもシステムは作れないよと思うのはそんなところ。いやなんちゅうか、全行程のうちのプログラミング「だけ」やるなら言語学習だけでいいのかもしれんけど…。プログラミングはマジで手段というか、なんていうか…
ユーザーがシステムを使うにあたり、テクニカルなプログラムがなされていることは、システムを使うのに全く関係ないと思う。裏側どうでもよくない？いや、どうでもいいわけじゃないんだけど、システムを使う場合には、結局使う部分が大事なんじゃないのって思う

なので今回はDB設計をしていく。

コミックス

コミックスは1-201しかないので、IDはautoincrementでなくID=巻数になる。もしかしたら201以外にもあるかもしれないけど、もうそれは連載当初から集めていた勢ではないので追えない。追える範囲でやるのだ。

話数

コミックスの中に話数がある、というイメージ。

キャラクター

ID、名前、読みがなは必須かな。父親と母親のキャラクターIDが持てると、家系図のようなツリー構造で表現できるので保持するようにした。また、どの家族に属しているのか（両津家か擬宝珠家かなど）もあるといいかな。
以前、俺屍で家系図をツリーにしたとき、GoogleかなんかのJSライブラリがあったので、それがあればなんとかなるなるケンタッキーかもしれない

中間テーブル/マスタ

登場人物は話数:登場人物が1対他になるため中間テーブルが必要。展開とシリーズはそれ単位で検索したい＆名称の統一をしたいので、マスタテーブル化。ただし、シリーズや展開をどう分類するかは難しいな。結局私がやりたいようにやる！ってなっちゃう。でもいいんだ。そういうデータベースなんだ。

家族、所属

これはマスタデータにあたるもの。家族テーブルはキャラクター:家族を多対1にするためのマスタ。
所属はちょっと複雑かもだけど、例えば読者からすると両さんは派出所勤務だけど、小町は葛飾署に勤務していると感じる。しかし両さんの所属は正式には葛飾署のはずなので、小町と両さんは同じ所属のはず。別に扱うために、読者の思う所属を所属名に入れ、正式名称は別に持つほうがよさそう。正式名称は補足情報。

実際プログラムしたり、コミックスを読んでいたら過不足あるかもしれないので随時変更していきたい。
また、初版と改版したもので収録話が違うこともあるかもしれないけど、連載当初勢ではないので（生まれる11年前から連載してるので）、普通に手に入れられる状態のコミックス準拠になる。