勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。数億規模のテーブルに対してのクエリを実行計画をみてチューニングしたり、テーブルのパーティション化をして前後で性能比較してきたりなどなどデータベース周りは個人的に大好きな領域で、ある程度勉強もしているつもりでした。勉強になることが多かったです。個人的に印象に残ったところを紹介します。正規化のやり方と、正規化が不十分な場合に変更が大変になるよねって話をわかりやすくされていました。逆にこう説明すれば設計の基本的な考え方が伝えやすいのかと気付かされました。業務としての全体像の分析と細かいデータ項目単位での分析とを繰り返すことでテーブル設計を洗練させる1つの帳票、1つの画面からどんなテーブルが必要でそのテーブルにどんな項目を持たせるのかを考えるところを設計の取っ掛かりにするのは比較的やりやすい。業務全体で考えると全然足りていないということがある。全体を俯瞰してざっくり大枠を見た上で、細かいところを見て、また全体に戻って・・・ということを繰り返すことでテーブル設計は洗練される。いうお話がありました。確かに、駆け出しの頃は部分見て設計して、業務全体の話をされてガッツリ手戻りしてとかとかは良くあったので、この話は駆け出しの方には先にしてあげるといいのかもなと思いました。大事だし、普段無意識にやってるよなと思いながら聞いていました。周辺テーブルに中核テーブルを使いやすい(selectしやすい)形で2次情報を記録する。事実はinsertでひたすら記録するだけ(updateはしない)。事実の記録なのでnullという状態の記録はない。変更型は、1レコードに対して更新していって最新を最新化し、selectしやすい形を作る。最近面倒を見始めたプロダクトで、そのプロダクトのメインとなるようなテーブルに対して登録パターンがいくつもあり、あるパターンだと10項目のうち3項目しか入らない(残りはnull)とか、あるパターンだと10項目全て入るとか、、、めちゃくちゃ暗黙の知識がないとテーブル定義だけでは読み解けないテーブルに出会いました。(しかもレコードして記録する前段の状態まで記録、複数概念を1テーブルに記録してたり)上の人に状況説明してテーブル設計させて欲しいとお願いして、テーブル設計大幅変更させてもらってる最中なのですが、、、こういう最悪のケースに陥らないように、こういう追記型の基本となる考え方をテーブル設計する人には持っておいて欲しいなと。このケースだと変更型でもselectしやすくないっていう、、、何がしたいのか謎な感じですが。次回1から作っていいプロダクトがあれば究極の追記型でテーブル設計したいし、この追記型の考え方は、変更型の考え方で設計する際でも基本で重要な考え方なので押さえておこうと思いました。今の僕のレベルだとちょっと勉強不足かなとおもいつつすごく興味があり面白そうだと感じています。キー制約、チェック制約などなどチェック制約以外は自分もガチガチに付けたい派で自分が設計するなら絶対制約は付けます。逆に外部キー制約で登録できないということををアプリでハンドリングしてその事実を記録するなり通知なり行う。いい気はするのですが違うのかな。テーブルに制約を付けないと、テーブルに壊れたデータが入るし特に外部キー制約においてはテーブル間の関係性がER図で見てわからないし悪いことしかないと自分では考えています。勉強会であったCHECK制約で型以上に値の範囲を絞る(個数に0は登録させないようにするとか)、ためにCHECK制約を使いまくるという考え方は自分はやったことがなかったです。テーブルに業務で扱うべき範囲の値が入らないように制約を定義することで、それを見るとどういう値を記録したいのかということが定義を見るとわかるので素晴らしいなと感じたのと、現場で導入させてくれと早速動きたいなと。(ただ最近大規模テーブル設計やったばかりだからなんかこれ以上あれこれ言ってかき乱すのもよくないか)テーブル設計について自分は自信があったのですが、、まだまだだなと感じさせられた勉強会でした。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。