後半からうしろのほうでみてたので感想を書きます。発表内容と自分の感想、メモがごっちゃになってるのでご注意ください。
まともなまとめは、#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめを参照ください。
20:30 - 20:50 @misoobu 論理削除と、そこでのElasticsearch活用（仮）
履歴テーブル
肥大化する -> パーテーション分ける
外部キー制約使いにくい
削除ログ
そもそもログはRDBにいらない？
そのシステムに本当に必要なものはなんなのか
Elasticsearch
JSONでINSERTできるのでMongoDB的に使える
QA
Q. Railsのpapertrail, Auditは検討した？
用途が違うので、という答えだったような。
20:50 - 21:10 moro 「論理削除を避ける(仮)」
絶版ステータス
Railsのscope使うとキレイだけど、default_scopeは違う。一時の楽のためにあとでツラくなりやすい。
論理削除を入れると、どこまでやるのかがあいまいになる
全部のテーブルに入れる？
JOINするときツライ
論理削除は伝染する
データの終わりを考えよう
データ、ドメインのライフサイクルを考えよう
21:10 - 21:30 gyugyu ホスティングの話＋論理削除と言う前に（仮題）
データが外部リソースと連携する場合の話。とても興味深い。
ユーザーは論理削除という言葉を使わない
開発者は内部事情を語りすぎる。もっとドメインをみつめて、開発者事情での変な言葉を使わないように、使わなくてすむようにしたほうが、幸せになれる。
論理削除の話を聞きに来て、DDDが出てくると思わなかった。これもひとつの飛び道具だった。
全体の感想
どの発表も入口は論理削除でしたが、出口はデータモデル、ドメイン設計をまじめに取り組もう、ユーザーの言葉に寄り添ったシステムを作ろう、というしごく真っ当なものでした。別に論理削除を完全否定はしていなくて、思考停止して論理削除を取り入れると不幸になるよ、というアンチパターンの話なんですね。
論理削除の周辺の話題として、データのアーカイブどうするというのと、オペミスにどう対策するかという話もあるけど、そちらはRDBMSのひとたちがすでに考えてきてることだと思うので、商用DB使うというのもひとつの解なのかもしれない。