「基本から学ぶ　テーブル設計　超入門！」(勉強会)に参加してみた感想や気づきなど

はじめに

「基本から学ぶ　テーブル設計　超入門！」という勉強会に参加したので、

勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。

＞＞基本から学ぶ　テーブル設計　超入門！

MEMO

今まで僕が参加した回の

現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて

まとめ記事を作ったので興味があれば是非見てください！！

現場から学ぶモデル駆動設計勉強会のまとめ記事

「基本から学ぶ　テーブル設計　超入門！」(勉強会)で印象に残ったところや気づきなど

自分は、データベーススペシャリストの資格を持っていたり、

現場で新卒の頃から８年間テーブル設計かなりしてきたり、

数億規模のテーブルに対してのクエリを実行計画をみてチューニングしたり、

テーブルのパーティション化をして前後で性能比較してきたりなどなど

データベース周りは個人的に大好きな領域で、ある程度勉強もしているつもりでした。

データベース関連のまとめも作ってるので興味があれば見てください！

初めてデータベースを触る方に向けて〜新人プログラマー時代の自分に伝えたいこと〜

僕はある程度データベース周り自信があったのですが、

この勉強会を通じて初めて知った設計の考え方などもあり、

勉強になることが多かったです。

個人的に印象に残ったところを紹介します。

テーブル設計入門においては正規化など難しい言葉をできるだけ使わず具体的なデータの例で説明すべき

勉強会では、ジャイアンツの選手の例で(僕はカープファンなんだけどな・・・しかも丸が例に出てたしw)

具体的なデータを使って正規化、部分関数従属性、推移的関数従属性などの言葉はあまり使わずに、

正規化のやり方と、正規化が不十分な場合に変更が大変になるよねって話を

わかりやすくされていました。

自分は、

資格勉強を通じて説明の時に当たり前のように難しい言葉を使うようになってしまっており、

知っているのに新人社員に伝え切れていなかったのかもしれないなと、

逆にこう説明すれば設計の基本的な考え方が伝えやすいのかと気付かされました。

業務としての全体像の分析と細かいデータ項目単位での分析とを繰り返すことでテーブル設計を洗練させる

１つの帳票、１つの画面からどんなテーブルが必要でそのテーブルにどんな項目を持たせるのかを

考えるところを設計の取っ掛かりにするのは比較的やりやすい。

しかし、それは業務の一部でしかなく、

業務全体で考えると全然足りていないということがある。

全体を俯瞰してざっくり大枠を見た上で、細かいところを見て、

また全体に戻って・・・ということを繰り返すことでテーブル設計は洗練される。

というお話がありました。

確かに、駆け出しの頃は部分見て設計して、業務全体の話をされて

ガッツリ手戻りしてとかとかは良くあったので、

この話は駆け出しの方には先にしてあげるといいのかもなと思いました。

一度その手戻りを経験しないと身に染みて理解はできないかもですが、、、

大事だし、普段無意識にやってるよなと思いながら聞いていました。

追記型と変更型という２つの考え方

追記型の考え方では、

中核テーブルに事実を記録し、

周辺テーブルに中核テーブルを使いやすい(selectしやすい)形で２次情報を記録する。

事実はinsertでひたすら記録するだけ(updateはしない)。

事実の記録なのでnullという状態の記録はない。

変更型は、１レコードに対して更新していって最新を最新化し、

selectしやすい形を作る。

最近面倒を見始めたプロダクトで、

そのプロダクトのメインとなるようなテーブルに対して登録パターンがいくつもあり、

あるパターンだと10項目のうち３項目しか入らない(残りはnull)とか、

あるパターンだと10項目全て入るとか、、、めちゃくちゃ暗黙の知識がないと

テーブル定義だけでは読み解けないテーブルに出会いました。

(しかもレコードして記録する前段の状態まで記録、複数概念を１テーブルに記録してたり)

上の人に状況説明してテーブル設計させて欲しいとお願いして、

テーブル設計大幅変更させてもらってる最中なのですが、、、

こういう最悪のケースに陥らないように、

こういう追記型の基本となる考え方をテーブル設計する人には持っておいて欲しいなと。

このケースだと変更型でもselectしやすくないっていう、、、何がしたいのか謎な感じですが。

今回のプロダクトだと勉強会で教えていただいた究極の追記型(全項目not nullとか)まではできないですが、

次回１から作っていいプロダクトがあれば究極の追記型でテーブル設計したいし、

この追記型の考え方は、変更型の考え方で設計する際でも基本で重要な考え方なので押さえておこうと思いました。

個人的には、追記型の中核テーブルの方は設計なんとなくできそうだけど、

周辺テーブルでselectしやすくとか、性能よくとかの方がいろいろ腕の見せ所な気がしてますし、

今の僕のレベルだとちょっと勉強不足かなとおもいつつすごく興味があり面白そうだと感じています。

増田さんが紹介されてた本を漁ってみようかな・・・

テーブルに制約をガチガチにつけるという考え方

テーブル制約、NOT NULL制約、一意性制約、外部キー制約、チェック制約などなど

チェック制約以外は自分もガチガチに付けたい派で自分が設計するなら絶対制約は付けます。

外部キー制約つけたらテストデータ突っ込めなくなるから・・・

って言ってる人を見かけたことがあるのですが、、、

そんな外部キー制約つけると登録できないテストデータを

用意して実施するテストって何だろうと未だに謎が解けないのですが、、、

多分逆に外部キー制約で登録できないということををアプリでハンドリングして

その事実を記録するなり通知なり行う。でいい気はするのですが違うのかな。

テーブルに制約を付けないと、

テーブルに壊れたデータが入るし

特に外部キー制約においてはテーブル間の関係性がER図で見てわからないし

悪いことしかないと自分では考えています。

ただ勉強会であったCHECK制約で型以上に値の範囲を絞る(個数に0は登録させないようにするとか)、

ためにCHECK制約を使いまくるという考え方は自分はやったことがなかったです。

テーブルに業務で扱うべき範囲の値が入らないように制約を定義することで、

それを見るとどういう値を記録したいのかということが定義を見るとわかるので

素晴らしいなと感じたのと、現場で導入させてくれと早速動きたいなと。

(ただ最近大規模テーブル設計やったばかりだからなんかこれ以上あれこれ言ってかき乱すのもよくないか)

テーブル設計について自分は自信があったのですが、、

まだまだだなと感じさせられた勉強会でした。

また、紹介しきれなかったですが

この辺りの話も面白かったので自分なりに現場にどう取り入れていくか

考えてみたいと思います！！