📛
はじめての縦持ちテーブル設計
はじめに
デザインテンプレートを自由に組み合わせ、ノーコードでLPが作れる管理画面を作りました。
そのLP管理のためのテーブル構成を悩んでいたところ縦持ちに出会い、雷を打たれたような衝撃の便利さだったので記録。
縦持ちとは?
いつもなら…
| タイトル1 | 画像1 | 本文1 | タイトル2 | 画像2 | 本文2 |
|---|---|---|---|---|---|
| title | img | text | title | img | text |
| title | img | text | title | img | text |
これを
| ID | タイトル | 画像 | 本文 |
|---|---|---|---|
| 1 | title1 | img1 | text1 |
| 2 | title2 | img2 | text2 |
の設計にしようの発想
縦持ちメリット
拡張性の神
横持ちなら属性が増えるたびにカラムを増やしていたのをやらなくてよくなる
並び順制御しやすい
表示/非表示を行単位で制御できるので、助かる
並び順も変えやすい~
JSON使わなくて済むことが増える
jsonで羅列するかカラムたくさんにするか…論争がこれで解決できちゃったりする
JSONだと検索や部分更新がつらいけど、縦持ちならSQLで完結する!たすかる
行は増えるけど…;;
縦持ちのデメリット
情報の全体像が見えにくい
横持ちと比較し、情報が少ないので全体像が見えにくい
クエリが複雑に
JOIN/GROUP BY/CASE が増えがち
クエリの可読性や保守性は横持ちより下がりがち
横持なら1件取得で終わることでも、複数行を束ねる必要が;;
鬼スクロールが必要
あたりまえだけど、カラムが減ったので行は増える。
→インデックス設計をちゃんと考える必要がある
まとめ
テーブル設計は、あとから直すコストが高い分、最初にどこまで将来を想像できるかが重要だと改めて感じました
行数やクエリの複雑さという代償はありますが、変更頻度が高いものを扱う際はとっても助かります
逆に、数値を扱うものとかだろ微妙かも…
今回の構成が唯一の正解ではありませんが、なぜそうしたかを説明できる設計を選ぶことが一番大事なのかもしれませんね
おしまい!
Discussion