話したネタ
- 論理削除とはそもそも何か?
- 物理削除とは?
- なぜ、論理削除が生まれてくるのか?
- SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
- 理由1: 心理的なハードルの高さ、怖さがある
- 理由2: 削除したデータを検索対象に入れたい場合がある
- 理由3: ログとしての用途
- 理由4: 誤操作をすぐに戻したい
- アンチパターンとは何か?
- なぜ、論理削除はアンチパターンとして捉えられるのか?
- 全てのSQL文のWHERE句に削除フラグが必ず入る
- LIMIT 1などが蔓延していく
- 論理削除に気づくきっかけは何か?
- テーブル設計や、規約から気づく
- 論理削除というアンチパターンをどのように解いていくか?
- 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない
- 要件をどのように設計すればいいのか?
- ORMの論理削除プラグインはあまり良くない
- 状態遷移として捉える方法
- Soft Delete と Hard Delete
- Doctrine 2 “Behaviours” in a Nutshell
- RDBにおけるStateパターンとは?
- UMLにある状態遷移図
- Stateパターンが使えないケースはある?
- FSM - Finite State Machine
- State Machineのプラグインをまず探す
- AASM - Ruby state machines
- 履歴テーブルを使った設計による解法
- 履歴テーブルをあえて使う強いモチベーションは何か?
- そもそも削除も更新もしない解法もある
- 発生した事実に忠実にモデリングすると、情報の削除や更新をしない、改ざんになる
- データ中心アプローチ(DOA) 椿さんとか佐藤さんとか渡辺さんとか
- T字形ER手法
- データ量が増えた場合にどうするか?
- Webシステムが流行る前後のデータ量
- イミュータブルデータモデル(入門編)
- 誤った操作をなかったことにしたい、という課題はまだ解けていない
- 教科書的なのは間違えにくいUI/画面設計を作る
- 遅延レプリケーションという解法
01:05:48
コメント
スクロール