SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less
削除フラグのはなし
Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能（Open Source Conference 2021 Online F...NTT DATA Technology & Innovation
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
ワープくん🤡 @warpbtn ぼく「なんか嫌な予感がするから警告いっぱい出したれ」 『このデータを削除すると復活できませんが本当に削除しますか？YES／NO』 『あなたは削除データが復活できないことを確認しました。YES／NO』 『以下の入力欄にDELETEと入力して削除を実行』 ？？？「なんかデータ消えたんですけど？」 2020-03-12 11:13:24
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
初心者向けにMongoDBの基本を解説しています。 この資料は2014/3/1のOSC 2014 Tokyo/Springで発表しました 。 2015/3/3最新の情報で一部アップデートしました。 2015/7/15MongoDB ver3.0ようにちょっと修正しました。 This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python ba
Kazuho's Weblog: さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた
さらば、愛しき論理削除。MySQLで大福帳型データベースを実現するツール「daifuku」を作ってみた 先のエントリ「論理削除はなぜ「筋が悪い」か」で書いたとおり、データベースに対して行われた操作を記録し、必要に応じて参照したり取り消したりしたいという要求は至極妥当なものですが、多くのRDBは、そのために簡単に使える仕組みを提供していません。 daifukuは、RDBに対して加えられた変更をトランザクション単位でRDB内にJSONとして記録するためのストアドやトリガを生成するコマンドです。 % daifuku dbname tbl1 tbl2 > setup.sql のように実行すると、指定されたテーブル（ここではtbl1とtbl2）にセットすべきトリガや、更新ログを記録するためのテーブル「daifuku_log」を生成するCREATE TABLEステートメントなど、必要なSQL文をset
はじめに kakurenboというgemはご存知でしょうか？paranoiaの欠点を克服すべく1年ほど前に私が開発を始めたgemです。(参考：Rails4と3で論理削除を行うためのGem Kakurenbo の紹介と今更論理削除Gemを実装した理由。 - 波打際のブログさん) issueやpullrequestを送信してくださる善意のコミッターの方々に支えられながら1年ほど保守をしてきました。その上で薄々は気がついていたのですが、どうしても認められなかった重大な欠点をハッキリと認識させられたのでポエムにしました。 論理削除gemの起源 kakurenboもparanoiaも、廃れてしまった acts_as_paranoid を再実装したものです。 これらのgemは導入するだけで、いつも使っているdestroyメソッドが論理削除メソッドに早変わりする素晴らしいgem...になるはずだったので
話したネタ 論理削除とはそもそも何か？ 物理削除とは？ なぜ、論理削除が生まれてくるのか？ SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か？ なぜ、論理削除はアンチパターンとして捉えられるのか？ 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か？ テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか？ 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか？ ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
InfoQ: データの削除は非推奨
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
論理削除の前に別テーブルに切り出せるかどうかを考えよう - Life is Really Short, Have Your Life!!
めっちゃよくまとまっているので、大変助かりました。 blog.mogmet.com t-wada氏の「とりあえず削除フラグはアカン」については、僕も全く同感です。論理削除をしなければならないビジネス上の理由がスッポリ抜け落ちている。「とりあえず削除フラグ立てて何かあれば戻せるようにすればいいンゴ」ってのは論理設計を放棄していると言い換えても良いし、「ユーザーの言葉ではない」という指摘も重要。こちらに書かれています。 ledsun.hatenablog.com じゃ、フラグやめてどーすんのって話。フラグを立てたくて立てる人はおらん(はず)。「削除フラグを追加するとSELECT時に常にWHERE句で削除フラグを引っ掛ける必要があるのでクソ」→「削除日や状態カラムを使おう」では解決にならん。t-wada氏の資料でも解決策で上げられてたけど「×」マークがついてます。下記に変わっても誰も嬉しくないと
それは前職のころ、今回の登壇者でもある @moro の発表にもあるような「要件としての論理削除はない」ということに熱く語りあったりしていたとかいなかったとか。 そして、ある日私が論理削除つらいということをつぶやいたところからこの企画は動きだしました。 このときは半分冗談で、いつか内輪で集まってやれたらいいかなというくらいだったのですが、今年の春にJxckさんの RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita をきっかけとしてインターネットで論理削除が盛り上がったこと、所属する組織から技術イベントをやっていこうという機運が高まっていたこと、この2つがちょうどいいタイミングで重なって、これはやるしかないなと思ったのでした。(とはいえ、Jxckさんのエントリからは半年も経ってしまっていますが…) @t_wadaさんの全体像と総論(と思ったら予想以上に踏み込んだ内
最近、機能の設計をレビューしたり話し合ったりするときに、うん・・・？ってなることがあって、でも駄目な理由をうまく説明できなかったのでちゃんと言語化してみる。ちなみにRailsの話です。 DBには事実だけを記録するようにする 色々開発してきて思ったのは、テーブルに状態を持たせるようにするとあっという間に複雑度が増してしまうということ。 status カラムや hoge_flag みたいなカラムを持つこと自体は全然否定しないけど、本当にそれが最適なのかは慎重に考えた方がよいと思う。 これは例ですけど、会員申し込み => 何か審査 => 会員登録完了 みたいなフローのアプリケーションを作る時に、会員情報のテーブルを１つだけ作りstatus 、approved_at みたいなカラムを突っ込んで、申し込み状態と申込み完了状態を アプリ側で頑張って判定しようとしている例はまれによくある。 こうすると何
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
データの完全消去 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "データの完全消去" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2012年4月） データの完全消去（データのかんぜんしょうきょ）とはハードディスク等の電子媒体内のデータを電子的にデータが残留しないように、特殊なハードウェアやソフトウェア等を用いた上書き処理で完全に削除する、コンピューターセキュリティ上の手法の一つ。 民生用向けでは、ハードディスク、フラッシュメモリの完全消去のための各種ツールが有名である。一方、電子媒体でも、光ディスク(CD/DVD/BD等)、光磁気ディスク(MO)の完全消去に関しては、必要性にもかかわらず、ハードディス
アプリケーション上でなにかエントリ（例えば記事だとかユーザだとか）を削除したとき、DB上の行は削除せず単に【削除済み】フラグを立てるだけという扱い方を 論理削除 と呼びます。 論理削除にはいろいろなメリットがあります。行削除のように関連する他テーブルへ削除が波及しないこと、エントリ復活ができること、障害時にデータ変更の経緯を追いやすくなることなどなど（デメリットもわんさかあるんですが、この記事の主旨からははずれるので別途お調べください）。 ところが論理削除の方針でDBを組んでいて困ったことはありませんか？ 「 メールアドレスは一意性(UNIQUE)制約をかけたいのに、それだと削除済みのユーザと同じメールアドレスが使えないことになる 」 論理削除と一意性制約、両立はできないのか？ できないと思っている方、多いと思います。実はちゃんとできます。DB製品によって実現方法がちょっと違ってくるだけで
8月32日を生きるみなさん、おはようございます。昨晩に開催された 論理削除 Casual Talks #1 : ATND について書きます。勤務先のセルリアンタワーで開催されるというので、これは俺得だと思い、運営をお手伝いする形で参加させてもらいました。みなさんのトークもばっちり聞けて、ありがたい機会でした。 @t_wada さんのトーク @yoku0825 さんのトーク @misoobu さんのトーク @moro さんのトーク 論理削除 Casual Talks #1 で「論理削除しない」という話をしました – moroのブログ gyugyu さんのトーク ハッシュタグ付きのツイートはこちらからどうぞ #ronsakucasual hashtag on Twitter みなさんのトークを聴いての雑感 「とりあえず論理削除」っていうのが極めて危険、とあらためて認識しました。本来は「当該デー
Rails4と3で論理削除を行うためのGem Kakurenbo の紹介と今更論理削除Gemを実装した理由。 - 波打際のブログさん
様々なわけがあってkakurenboは非推奨です。新規のプロジェクトではkakurenbo-putiの使用をおすすめします。 Kakurenboとは Rails4及びRails3で論理削除を行うためのGemです。paranoia及びacts_as_paranoidと互換性があるので、gemを置き換えるだけでそのまま動きます。(動かなかったらissue投げてくだしあ＞＜) なんで今更論理削除のGemを実装したのか 今更開発しなくても論理削除のGemは山ほど出てきますが、なぜ開発しなくてはならなくなってしまったのか経緯に触れておきます。 acts_as_paranoid 論理削除の本家と言ってもいいレベルの知名度です、だがしかしいつまで立ってもRails4に対応しない。 rails4_acts_as_paranoid 既存のバグほったらかしで使えない。(メモリ関連のバグがありSQLクエリが永遠
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
do-not-delete-softly
全体がいい感じになるために、私たちRailsをホームにするWeb技術者ができること/let-our-whole-system-grow
先日の第4回 CakePHP 勉強会で発表した内容でもあるのですが、簡単に SoftDeletable Behavior の使い方をまとめました。（少しだけ発表ないようにない追加情報もあります） SoftDeletable Behavior はソフトデリート（論理削除）を簡単に実現してくれる大変便利なビヘイビアです。論理削除とは DB から DELETE するのではなく削除フラグを設けて DELETE する変わりに削除フラグを立てて削除したことにすることです。 一番参考になるのはやはり Bakery です。英語が苦にならない方は私の説明よりも下記エントリを見る方がいいです。 Soft Deletable Behavior (Articles) | The Bakery, Everything CakePHP 勉強会で発表した資料は下記にありますので、よろしければこちらもご覧下さい。 Cak
データベースの論理削除と物理削除
データベースの論理削除と物理削除 データベースからデータを削除するには、「論理削除」と「物理削除」2種類の方法がありまります。 物理削除とは文字通りDELETE構文を利用しデータベースよりレコードを完全に削除してしまうことをです。 論理削除とは、データベースにフラグとなるフィールドを作成しておき、削除時に削除フラグを立てることにより、仮想的に表示時に見えなくしてしまう処理になります。 私がデータベース設計を行う際には論理削除を採用するのですが、論理削除のメリットデメリットをまとめておきたいと思います。 論理削除のデメリットが、物理削除のメリットになります。 メリット 誤ってDBからデータが削除された場合に簡単に復元できる デメリット 表示時にWHERE句にフラグの確認が必要になる 削除処理をUPDATE構文で行う為、非直感的である レコードが肥大し続ける為データベースのコストパフォーマンス
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
投稿内容の管理やチェックを運営が行わないことを明言しているSNS「Parler」に投稿されたムービー合計109万8522本を、ハッカーがスクレイピングで取得したことを明らかにしています。取得された映像は、SNS公開用に処理されたものではなく、アップロード時点の未処理ファイルで、メタデータも残った状態だとのことです。 70TB of Parler users’ data leaked by security researchers | CyberNews https://cybernews.com/news/70tb-of-parler-users-messages-videos-and-posts-leaked-by-security-researchers/ Parler Is Gone, But Hackers Say They Downloaded Everything First
2015/4/27(月) SQLアンチパターン読書会 ：番外編「論理削除の四方山話」に参加してきました。 DoorKeeper https://sqlap.doorkeeper.jp/events/23719 以下の書籍をターゲットとした読書会なのです。 場所は前回と同じく、品川シーサイドにある株式会社マーベラスさんです。 参加者は14名かな。 前回の読書会で全25章を終えたので、今回は特別編のような位置づけなのです。 今回のテーマは「論理削除」！ そして今回はなんと @t_wada さんに加え、そのお父さんであり書籍の監訳者でもある和田省二氏も参加してくださいました！ 以前、DevLoveでも和田さん親子によるSQLアンチパターンのイベントがありましたね。 そんときは私も参加してブログにも書きました。 makopi23のブログ： 「SQLアンチパターン・レトロスペクティブ - データベー
Railsライブラリ紹介: 論理削除をサポートする「rails3_acts_as_paranoid」 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、鈴木です。 Rails3 で論理削除をサポートするライブラリ rails3_acts_as_paranoid をご紹介します。 rails3_acts_as_paranoid (https://github.com/goncalossilva/rails3_acts_as_paranoid) rails3_acts_as_paranoid は Rails2 時代にあった acts_as_paranoid の Rails3 対応版です。 ※2013/07/25 追記: Rails4 対応版は rails4_acts_as_paranoid です。（see 「Rails4 ライブラリ対応状況調査」） 論理削除とは アプリケーション上でデータを削除する操作をした場合の方式に、物理削除と論理削除があります。 物理削除は、アプリケーション上で削除する操作をすると、実際にデータベースのレコ
論理削除Casual Talks #ronsakucasual でMySQLで論理削除する話をしてきた
論理削除 Casual Talks #1 : ATND に行ってきました。 アプリケーション方面では色々あるし、DBAから見ても良いことはないはず…と思ってましたが、 *ちゃんとMySQLの都合に沿ってやれば* 意外と忌避する理由もないことにふと気付きました。途中で3回くらいテーマ変更して最終的にこの形に落ち着いたカタチです。はふん。 ごめんなさい、当日流していたスライドに致命的な誤り（5.5以降ではなく、5.5以降 *ではない*）がありました。。まとめてくれた方ごめんなさい…＞＜ DBAっぽく、という背景があったので、「論理削除？ それUPDATEじゃん」というのが割と前提にあります。「DELETEじゃなくてUPDATEなんだから、削除とか言わずにスーパー非表示フラグでいいじゃん、システム的に *ちゃんとMySQLの都合に沿ってやれば* はそこまで変わらないし」というのが個人の見解です。
論理削除と、そこでのElasticsearch活用 | 論理削除 Casual Talks #1 / soft_delete
イベント: 論理削除 Casual Talks #1 : ATND https://atnd.org/events/68902 発表者: https://twitter.com/misoobu
はじめに kakurenboを公開してから1年が経過し、いろいろ思うところがあり acts_as_paranoid の呪縛から脱却した論理削除gemである kakurenbo-puti を公開しました。 経緯についてはこちらをご覧ください。 kakurenbo-puti kakurenbo(acts_as_paranoid系のgem)はrailsの削除機能を論理削除に置き換えることを目的に作られたgemですが、kakurenbo-putiはrailsに論理削除機能を追加する目的で作られたgemです。 置き換えとは異なり、ActiveRecordを魔改造するgemではありませんので、ActiveRecordの内部構造に左右されにくく、コードもシンプル(コアファイルは70行程度)になるため、堅牢さや保守性の面でかなり優秀なgemと言えると思います。 alfa-jpn/kakurenbo-put
論理削除が奪うもの
論理削除が奪うもの JPOUGのAdvent Calendar 12/10担当です。 12月 - 忘年会シーズンです。酒で記憶を失っている際に、怒ったとか、近くにいた人にカラんだとか、脱いだとか、毛を燃やしたとか、エレベーターホールにズボンが脱ぎ捨てられていたとか、会議室で靴が発見されたとか、そういう事件が多発する月ですね。皆様いかがお過ごしでしょうか。 微塵も記憶がない状態で、やらかした内容を色々な人から聞かされるにつけ、穴を掘って蓋してセメントで埋めてもらいたくなるのは常ですが、こういう時はどんな対処を取ればいいんでしょう。 得てしてロクでもない行動を取った時の翌日における参加者の記憶力の良さと来たらFlight Recorderも真っ青です。 なんとか失敗を無かったことにしたいと立ち回りたいですが、まあ無理です。各所にヒアリングを重ねれば重ねるほど確度と精度が高まります。エビデンスま
blog: 削除フラグって必要？
休日なので、結論の出ない軽い話題を。 DB設計の時に、場合によっては全テーブルに「delete_flag」なんていう名前でフラグを持たせることがままあります。 テーブルのデータを実際に削除せずに、「削除フラグ（delete_flag）」をONにすることで「削除したものとして扱いますよ」というフラグです。 ちなみに、実際にデータを削除することを「物理削除」、削除フラグを立てて削除したものとみなすことを「論理削除」と呼んだりもします。 この削除フラグ、特に意識せずについつい付けてしまうことが多いのですが、本当に必要なのかね・・・？というのが趣旨です。 ※恐らく日本では、ある程度の規模以上のシステム開発の常識では削除フラグは絶対必要だと考えられていますので、開発リーダーに「削除フラグ要らないんじゃないっすか」みたいなことを言ってみて一蹴されても責任は負いません。 ■削除フラグの根拠 削除フラグを
データを扱うアプリケーションの注意点
ここでは主に業務アプリケーションで、データを扱うときに、注意する点について述べます。 削除パターン 親子関係にあるとき、親が削除されたときに子をどうするか決めておきます。 RESTRICT 子があるとき削除できない CASCADE 子もすべて削除される SET NULL 子の参照をNULLにする 論理削除 削除フラグを立て子はそのままにする 論理削除を行なう場合の注意点 データを削除する際、実際物理的にはデータベースから削除せずに見かけ上消す論理削除がしばしば用いられます。この利点は、誤削除しても復活させる手立てを残しておくことや、削除されたものを後で参照できることなどがあります。削除というよりは無効化という方が適切な場合があります。 例えば、案件テーブルに担当者を入れる項目があったとしてます。論理削除であれば、担当者が退職した場合でも、あとで誰が担当者であったかを分かるようになります。一
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
PostgreSQLアンチパターン
ぼく「嫌な予感がするから警告いっぱい出したれ」データ削除は三重確認設計に→？？「なんかデータ消えたんですけど？」
論理削除が云々について - mike-neckのブログ
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
論理削除gemを1年ほど保守してみて。重大な欠点にやっと気づいたポエム。 - 波打際のブログさん
27. 論理削除とは何か？どのような解法があるのか？ w/ twada | fukabori.fm
論理削除がデータを汚している - jfluteの日記
https://atnd.org/events/68902
論理削除 Casual Talks #1という夢を見たんだ
最近アプリケーションの設計するときに気をつけてること - suusan2号の戯れ
論理削除と一意性制約を両立させる方法・DB製品別 - Qiita
イベント「論理削除 Casual Talks #1」の運営をお手伝いした、あと自分用メモ #ronsakucasual
論理削除フラグという名の死亡フラグ - @ledsun blog
[CakePHP] SoftDeletable Behavior で論理削除 | Sun Limited Mt.
MySQLで論理削除と正しく付き合う方法
SNS「Parler」に投稿された100万本・80TBの映像をメタデータ付きでハッカーが取得したことが判明
makopi23のブログ SQLアンチパターン読書会 ：番外編「論理削除の四方山話」に参加しました
kakurenbo-putiというrails4.2に対応した論理削除gemの紹介 - 波打際のブログさん