削除フラグの要否について語るスレ [転載禁止]©2ch.net

**NAME IS NULL** · 2015/10/18(日) 11:59:39.60

削除フラグは不要か？
必要な場合があるとすれば、どのような場合？

**NAME IS NULL** · 2015/10/18(日) 14:21:15.03

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

**NAME IS NULL** · 2015/10/18(日) 16:51:15.33

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

**NAME IS NULL** · 2015/10/18(日) 17:47:24.49

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

**NAME IS NULL** · 2015/10/19(月) 18:03:07.47

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

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

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

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

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

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

5 · 2015/10/19(月) 18:10:05.16

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

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

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

**NAME IS NULL** · 2015/10/19(月) 18:37:57.76

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

**NAME IS NULL** · 2015/10/20(火) 10:22:42.95

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

**NAME IS NULL** · 2015/10/20(火) 10:42:02.37

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

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

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

**NAME IS NULL** · 2015/10/20(火) 10:46:20.26

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

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

**NAME IS NULL** · 2015/10/20(火) 10:52:00.41

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

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

**NAME IS NULL** · 2015/10/20(火) 10:54:21.53

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

**NAME IS NULL** · 2015/10/20(火) 10:56:44.30

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

**NAME IS NULL** · 2015/10/20(火) 11:05:47.82

個人情報技術者かな？

**NAME IS NULL** · 2015/10/20(火) 11:48:25.21

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

**NAME IS NULL** · 2015/10/20(火) 11:50:02.90

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

**NAME IS NULL** · 2015/10/20(火) 12:37:02.60

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

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

**NAME IS NULL** · 2015/10/20(火) 12:39:11.59

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

**NAME IS NULL** · 2015/10/20(火) 13:06:46.82

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

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

**NAME IS NULL** · 2015/10/20(火) 13:10:36.27

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

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

**NAME IS NULL** · 2015/10/20(火) 13:14:31.29

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

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

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

**NAME IS NULL** · 2015/10/20(火) 13:53:19.02

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

**NAME IS NULL** · 2015/10/20(火) 14:06:51.14

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