削除フラグの要否について語るスレ by 2ちゃんねるブラウザ[土下座] #dogeza

ユーザーは削除されました。でもそのユーザーの情報は見れます。みたいに
（選択項目としては）削除されたが、情報として残す時に使う。
削除フラグはという名前が混乱の元になってるだけで、単に無効フラグなだけ。

何で削除フラグというとすぐユーザーデータの話になるの？

>>3
普通のデータの無効フラグとかならたいして問題にならないのに、ユーザーデータの削除フラグには親のかたきのごとく噛みついて来る奴がいるからだろ

俺の考える削除フラグの代替案

■削除フラグを辞めて状態（status）を追加する
単純な有効/無効の切り替えならこれでOK

■会員が退会、社員が退職、商品が廃盤になる時は、履歴テーブルに移す
ただし、移す時は最低限の個人情報のみとする。
会員・社員なら名前、商品なら商品名。
これだけだと重複した名称も多いだろうから、個人特定に繋がらない（はず

■データの復元はしない
復元が必要な場合、削除フラグのように見せなくするか、
全く同一のテーブルをもう1つ用意するしか無い（DBMSによっては違うかも
だからユーザーには「退会したら復元できません」と規約で謳うしか無い。

○メリット
・存在するデータのみをテーブルに置いておける
・個人情報保護に強い
・基本的には退会時にINSERT/DELETEするだけなので簡単
・退会理由（退職理由、廃盤理由など）や日時も保存できる

●デメリット
・テーブルが増える
・名前以外を参照させたい時に困る
・画面設計的に作業が増える
・元テーブルのバックアップを随時取る必要がある

削除フラグを使うか別の方法にするかの判断は1つしか無いと思います。
それは「後からデータを参照・復元する可能性がどの程度あるか？」です。

会員サービスなど不特定多数が触るシステムの場合は、
うっかりさんが多い可能性があるので、安易に物理削除は面倒になるかもしれません。

逆に社員管理や商品管理など自社内で操作する場合は、
自分たちがルールを守ればいいだけだから、>>5の方法が有効だと思われます。
あとは要件次第で設計を変更したりつけたりたりしていけばいいかと。

外部キー使ってると一蓮托生で消えちゃうからあわててフラグで対応して
それ以降ずっと何も考えずに削除しない方法を採用ってケースが多いと思うのだが
消してもいいものと消えちゃ困るものを分けることも検討する、でいいのでは

>>5
いつまで個人情報にこだわってんだよ

>>6
> 削除フラグを使うか別の方法にするかの判断は1つしか無いと思います。
> それは「後からデータを参照・復元する可能性がどの程度あるか？」です。

後からデータを参照・復元する可能性がある場合、削除フラグに限らず、どのような方法でも
要件を満たす事は出来る。

故に、上記引用部分は誤り。

>>5
> ただし、移す時は最低限の個人情報のみとする。
> 会員・社員なら名前、商品なら商品名。
> これだけだと重複した名称も多いだろうから、個人特定に繋がらない（はず

どうしてこれにこだわるんだ？
削除フラグ（論理削除）に絡んだデータベース設計とは関係ない話。
商品情報に個人情報など関係ない。

>>8-10
相変わらず他人の意見に突っ込むことしか出来なくて草www

なら、お前らはどう考えてるのか書けばいいだけじゃん。
それして自分が煽られるのが怖いか？

止めとけ。どうせ「要件次第だ」って逃げるのがオチだから

個人情報に関係ない事例で考えていけば良いと思うよ

個人情報技術者かな？

>>11
5が酷すぎて、お前と議論する気になれない

>>5
> ■削除フラグを辞めて状態（status）を追加する
> 単純な有効/無効の切り替えならこれでOK
なぜそれでOKなんだ？

>>15
どこがどう酷いのか言わずに書きっぱなし？

つか、5みたいな目に合うなら誰も意見なんてしないわな。
自分のブログで適当に言ってるほうがマシだ

ここは隔離スレなだけだから。マジレス厳禁。正解欲しけりゃ勉強会でも参加しろ

>>17
> どこがどう酷いのか言わずに書きっぱなし？
だから、誰もが無料で添削してくれるなんて思うな

> つか、5みたいな目に合うなら誰も意見なんてしないわな。
誰もが同じ目にあってないのはなぜなんだか、ちょっと考えてみる必要があるんじゃないすかね

>>17
> どこがどう酷いのか言わずに書きっぱなし？

お前、何度も要求仕様と実装仕様の区別がついてないって言われてるけど、
その意味、まだ理解できてないだろ。

>>5
せめて、
手段1：～～～
メリット：～～～
デメリット：～～～

手段2：～～～
メリット：～～～
デメリット：～～～

という構成にしてくれませんか。
個人情報云々が無くなればなお良し。

元の話は削除しないでフラグにすることの是非だったはずなのに
いつのまにか削除しないことが大前提になってる件ｗ

いや、元スレでは最初から削除しないときに削除フラグを使う是非だった

まあどうせ隔離スレだからまともな議論なんて期待しちゃいないが
論理削除も物理削除も「削除」で済ますべきかどうかぐらい判断付けろよ

まともな議論したいなら、ちゃんと用語を統一して定義しとけよ

>>24←何言ってんのこいつ
誰か翻訳してくれ

翻訳: 削除フラグはNG、状態と呼べば水に流してやる

違う違うそこじゃない

偉い人「特別謝恩セールメールをユーザーさんに出して」
素人に毛の生えた部下「OK」

こういう時、WHERE句に削除フラグの条件入れるのを忘れて大迷惑。
なんてことになるのが怖いんだよね、多分？

削除フラグはダメだがステータスならよしとする風潮
削除フラグもステータスもダメだが、available_fromとかavailable_toという日付ならよしとする風潮
そもそもUPDATEするなという風潮

(A)全ユーザーテーブル
ユーザーIDとユーザー名
その他半永久的に参照したい項目
絶対に削除しない

(B)ユーザーデータテーブル
ユーザーIDとその他の項目
ユーザーが退会したら削除する

でいいじゃないか
ユーザー一覧は(B)から取得する
ユーザー名は(A)をLEFT JOINして取得する

☆ 日本の、改憲をしましょう。現在、衆議員と参議院の両院で、
改憲議員が３分の２を超えております。『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆