DBのtableの設計
DBのtable設計の大まかな流れ
どのデータを用いて主キーを設計するか
tableに対し自然言語のドキュメントを書くべき
DBのtableやcolumnの命名
ある選択肢のみ許容するcolumnを定義する際の方針
table構造の修正
参考
/mrsekut-book-477419087X/176 (第6章 データベースの設計とドメインオブジェクト)~
#WIP
疑問とか
どの選択肢をDBで管理するか
商品と価格のtableの設計
OR型をtable上でどう表現するか
ER図
https://speakerdeck.com/masuda220/table-design
増田さん
コト(事実)を扱うコトtable
記録のタイミングが異なるデータはtableを分ける
/mrsekut-book-477419087X/186
過去のデータは変更しない
赤伝と同じ感じで、「取り消しデータ」と「新データ」を新しく追加する
そうなると、「取り消しデータ」にに対応できるように型を考慮する必要が出てくるな #??
/mrsekut-book-477419087X/187
コトの記録の問題点と対応
少ないcolumnのtableがたくさんできるので、joinが沢山必要になる
コトの再生にコストがかかる
例えば、「残高」をコトベースで考えば
複数の入金データと、複数の支出データがあれば、それらを累積的に加減すれば、現在の残高を算出できる
しかし、これだと残高を知りたい時に、コレまでのrecordを全部見て計算する必要がある
パフォ的問題がある
パフォの問題が出る場合のみ状態tableを別途作る
状態tableは、コトtableが更新されたら更新していく
この時にUPDATE文を使わない
同時更新でなくていい
Event Sourcing
UPDATE文は使わない
/mrsekut-book-477419087X/188 (参照をわかりやすくする工夫)
NULLについて
nullの表す意味
可能な限りNOT NULL制約をつけろ
create, updateなど日付に関する言及があれば読みたい #??
#??
今のところフラグっぽいものを想定しているもののデータ型はどうするか?
boolean?
これは微妙だと思う
あるのか知らんが
拡張性がない
0/1 ?
例えばON、OFFみたいに具体的に表した文字列?
普通は、そのidと文字列を組み合わせた別のtableを作って、それを紐付けるかmrsekut.icon
でも、そこまでする必要もないんだよなーみたいなもの
これって、MySQLの型をどうするか、の話だな
表示順columnを別tableに分ける
https://zenn.dev/rebi/articles/28c7f1fee5730a