タグ

削除フラグに関するledsunのブックマーク (2)

  • 論理削除が云々について - mike-neckのブログ

    今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意

    論理削除が云々について - mike-neckのブログ
    ledsun
    ledsun 2015/03/26
    今のディスクスペースやメモリ容量なら、そろそろ論理削除(UPDATE文で状態を更新する)実装はやめてもいいんじゃないの?というお話。
  • 論理削除がデータを汚している - jfluteの日記

    ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か

    論理削除がデータを汚している - jfluteの日記
    ledsun
    ledsun 2015/03/01
    “個人的には、業務上重要なテーブルに関しては、 しっかりと「削除履歴テーブル」を用意”
  • 1