事実を更新しない解法パターン

最新の状態（ステータス）を知りたいという要求は多くの業務で存在する

e.g. CS問い合わせシステムでの問い合わせ受付や回答を考える

http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuKhDAyaigLHuEhN_SMFBqmaTZvk0ZDbF-wS_sJr3ePeBgxYd2vUkBePKM-lJTJknQtWsVUcpcKrSjJ3RddMtFjqx-KL3wzFEJK06q1uq4R0Dk2n7A8Qn4HhHRNewUzxpjLE05a0OO7CnBOFAGhm0vS1DmXuqDJMw-JNe7a4t6Qog6ke8BeVKl1HWa0C0#.png

一定良さそうだが未回答の問い合わせを抽出したいという場合、クエリが現実的な速度で返せないかもしれない

以下でいう「問い合わせ」が著者がいうロングタームイベント。イベント自身にステータスを持たせてイベントエンティティを更新する（通常イベントエンティティを更新することはない

http://www.plantuml.com/plantuml/svg/SoWkIImgAStDuKhDAyaigLHuEhN_SMFBqmaTZvk0ZDaArLne8fukNBgww8AFctO-RcvxtBpdSTD-89kh5cOSXhf5ZvlMWvGsBNxSF1d20Dj1M1bMYu62M1K_Nx7kQSTIx7BFfYzzDhC9fnkVzaz_idi6n56OubXTyRIjzUaw95y_wsvzkdVoYuRMfvsRW0oWMMWYO5DmMO1G36GZN3bxtlErKu16GHXW4w1ikFNeaLTJerjJJLGSS14LKRgw-JNOWuje_TNeWKE2JeXlkHnIyrA0AHO0#.png

適用開始日、適用終了日をエンティティにもたせて抽出

デメリットは主キーに適用開始日を含める必要があり、IDだけでは最新を特定できない

Git などのバージョン管理の仕組みと同じく世代のデータをスナップショットで持つ

デメリットは乱用するとクエリが複雑になる

サブタイプを使った継承パターン

無駄に複雑化していないかで属性束ねるパターンかな、PofEAA より

サブタイプごとにテーブルを作る（スーパータイプのテーブルを作らない）

あまりこういったケースは実際には多くないらしい

スーパータイプ、サブタイプいずれもテーブルを作成する

論理モデルと同じ粒度で理解しやすい。性能問題になる場合もある、慎重に

記録すべき「事実」を明らかにして更新されないように設計するという鉄則