削除フラグに入力する値は二種類が好ましい。
1とか0とか9,2とかNULLを含ませるのは好ましくない。
postgresの場合、削除フラグを表す場合、boolean型を使用してカラム名に「deleted」などの命名をするのが主流。
postgresでなくてもCheck制約を付与すれば妨げられる。
アプリケーション側のヴァリデーションのみで制約かけるよりもテーブル上で制約かければアプリケーションのバグから守れるし、DDLに記載することになるので明文化できる。
履歴は残しておいたほうが良いよって話
消費税率が変わった前後のタイミングで購入と払い戻しが発生したときに
売上を計算しなおさなきゃみたいなことがある。
設定マスタの消費税率カラムを0.05から0.08にした上書きしてしまうと、税率8パーセント以降の買い物はその値を参考にすればいいけど、税率5パーセント時の買い物を払い戻して計算しなおすために消費税カラムを参照すると0.08なので8パーセントの消費税率で計算されてしまう。買った当時は5パーセントだったのに計算しなおすときは8パーセントになると計算が当然ズレる。
解決策としてはテーブルに履歴テーブルを積ませる。
消費税マスタとしてデータを抽出して消費税の変更履歴を積ませる。
積ませる際には税率と有効開始日と失効日をカラムにする。
| 消費税率 | 有効開始日 | 失効日 |
|---|---|---|
| 0.05 | 1997-04-01 | 2014-03-31 |
| 0.08 | 2014-04-01 | null |
ほかにも発送状態を追う履歴を管理する場合
| 売上ID | 発送状態 | 登録日時 |
|---|---|---|
| 1 | 発注済 | 2014-03-31 11:59:59 |
| 1 | 配送済 | 2014-03-31 15:59:59 |
| 1 | 納品済 | 2014-03-31 18:59:59 |
| 2 | 発注済 | 2014-03-31 23:59:59 |
売上一つの状態を上書きしていくより、いつ発注していつ配送して、いつ納品したのか履歴が残るのでトラブル時に対応しやすい。