2作目のポートフォリオでDB設計の工程に入ったところ、ER図が全く読めませんでした。
そのときの正直な感想がこれです。
はじめてのことすぎて全然わかんない。バックエンドの知識足りてなさすぎるのかな？
Web制作でWordPressは2年触ってきましたが、テーブル設計を自分でやるのは初めてでした。
「バックエンドの知識不足」だと思っていました
止まった原因を、最初は知識量の問題だと考えていました。
でも切り分けてみると、必要な前提知識は、WordPressで毎日触っている構造とほぼ同じでした。
| 自作アプリ | WordPress |
|---|---|
profiles（ユーザー） |
wp_users |
items（カード1枚 = 1行） |
wp_posts |
feed_sources（カードにぶら下がる設定） |
wp_postmeta |
sort_order（並び順） |
menu_order |
visible（表示するか） |
post_status（publish / draft） |
wp_posts の post_author には、wp_users のどの行かを示す値が入っています。
これが外部キーの考え方そのものでした。
新しい概念を覚える話ではなくて、すでに知っているものに名前がついていた、という構図です。
ただしWordPressには、外部キー制約が張られていません
調べていて気づいたことがあります。
WordPressのテーブルには FOREIGN KEY 制約がありません。
post_author には wp_users.ID を指しているつもりの数値が入っているだけで、
整合性はデータベース側では保証されていない状態です。
初期のWordPressが外部キーを扱えないMyISAMを前提にしていたことに加えて、
柔軟性と、更新のたびに整合性を確かめるコストを避けたことが理由として説明されています。
つまり自分が毎日見ていたのは、外部キーのある設計というより、
外部キーがない状態で運用されている設計のほうでした。
参照関係の読み方は同じでも、制約があるかどうかは別の話です。
自作アプリのほうは制約を張るので、ここは読み替えが要ります。
実データの表を見ても、まだピンときませんでした
対応表を作り、カード7枚が items にどう入るかを実データの表にして見ても、
正直まだよく分かっていませんでした。
ここは格好つけずに書いておきます。
つかめたのは読み方の入口までで、「なぜこのスキーマなのか」は腑に落ちていません。
「理解してから進む」をやめました
そこで、「なぜこのスキーマか」の言語化は、実際に CREATE TABLE を書く工程まで送りました。
1作目が7日で終わったのも、学習フェーズで止まっていたのが作り始めたら進んだのも、
自分が手を動かしながら理解する型だったからです。
止まっている場所で粘るより、書く工程まで持っていったほうが早いと判断しました。
調べる範囲を先に絞りました
そのうえで、空き時間に調べる範囲を決めました。
作業時間は削っていません。学習に入って停滞するパターンを避けたかったからです。
調べるもの
- テーブル・カラム・行
- 主キーと外部キー（ここが分かればER図は読める）
- 1対多・1対1の記号
CREATE TABLEJOIN
調べないもの
- 正規化理論の細部
- インデックス設計
- トランザクション分離レベル
下の3つは面白そうで、沼にハマる自信がありました。ただ今回のアプリでは使いません。
何を調べるかより、何を調べないかを決めるほうが効きました。
おわりに
「バックエンドの知識が足りない」という漠然とした不安が、
「主キーと外部キーの読み方が分かっていない」という具体的な穴に変わりました。
この躓きは、受講を検討している講座が本当に自分の穴を埋めるのかを判断する材料にもなりました。
不安のままだと比べようがないので、実例に落ちたのは収穫でした。
