削除フラグのはなし

PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントの ユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)

[habuakihiro]

面白かった。この話は「削除する」ってのはどういうことなのかという話に行き着くんだよなぁ。userの削除というのは退会なのか取引停止なのかみたいな。ビジネスイベントの見出し方につながる。

[SiroKuro]

隣のチームが「存在」「削除」「仮削除」「仮仮削除」「暫定削除」「削除予定」「仮削除予定」「暫定削除予定」まで作っててバカかと思った。さらには削除後退避テーブル100個も用意しやがった件。

[daisuke-m]

PKをマイナスって、面白いな。

[lizy]

削除フラグよりは、削除データテーブルへの移動の方が安全な気がしている

[fukken]

flagという名前なのだから当然2値だろう、そんな風に思っていた時期が私にもありました

[neogratche]

DBの事は１ミリも分からんけど言ってる事と背景がマッチングしてて見てて面白かった

[tyoro1210]

最近、待避テーブルに移行した。

[y-kobayashi]

PostgreSQLはwhere句付きのユニークインデックスが貼れるんだ。便利ね。MySQLにもほしい。

[katzchang]

実践的なデータ設計パターン。履歴管理パターンとかも知りたいな。

[kkotyy]

削除フラグを2値型じゃなくてchar(1)で定義している場合は、Nullだったり0だったり1だったりするんで困っちゃうんだよな。where Deleted<>'1'という聞き方になる。。。

[teematsu]

削除時にトリガーで履歴テーブルに移動、部分インデックスでユニーク制約実現

[bobbyjam99]

削除フラグのはなし :

[a_suenami]

TLに流れてきたから読んだ。主キーの正負で削除済みかどうかを見分けるのはちょっとないなーという感じする。あと「リレーション」じゃなくて「リレーションシップ」だと思います。

[t-wada]

p.73 の「終わりに」から後が本番。大事なことは "しっかり業務分析" "DB は DB の論理構造を守る" だな。

[snomof]

DB設計アプリケーション側で大変な思いをしないでも論理削除を使うことができる方法。やっぱRDBは設計がしっかりしていれば書くコードも少なくなる。安心できる

[yocchi24]

超勉強になりました！凄くいいです。今すぐ導入したいです。部分INDEXは直ぐ使えそう。リレーションの方はしっかり設計してから。

[kenomi]

削除フラグ（無効フラグ）を使う場合はこういった事も考慮しましょう。

[motchang]

論理削除

[rdfrk]

データベースの整合性はデータベースが守るべし。インデックス、トリガーなどを使って、整合性を守れる仕組みを作りましょう、という話。 Reading: 削除フラグのはなし

[kizashi1122]

削除フラグ

[bluerabbit]

削除フラグにユニークキー制約を付けて削除フラグ＝有効のレコードを１レコードに保つ

[hiro_y]

削除フラグ、というか物理削除しないで残しつつ運用する仕組み

[a2ikm]

部分インデックスで有効なレコードにユニークかけるのか、なるほど。論理削除は難しい

[perezvon]

primary_key < 0 ならば削除とみなすというテクニック

[kesuuyof]

すごくおもしろいし、ためになるスライド。83ページ一気に読める

[loungep]

削除フラグを使わずに「削除したことにする」幾つかの方法。

[shin1x1]

退避テーブルの方が後の管理は楽

[crosscrow]

DBのテーブル設計における削除フラグについて

[aki03]

これは非常に参考になる！ DBをもっと使いこなそう！

[o_hiroyuki]

database

[wwolf]

素晴らしい

[y0sh1kaw]

ためになります。

[paschen00]

ORMと相性がいいのは別テーブルかな

[src256]

削除フラグ

[tyamamoto]

t

[smotokezuru]

データ削除をON/OFFで表す、よくある設計のメリットデメリット考察

[s-tomo]

死亡フラグとの類似性を考えてみたい。

[slash_01]

面白い。しがらみなく気ままにアプリを作ってみたい。