削除フラグの要否について語るスレ [転載禁止]©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

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

**NAME IS NULL** · 2015/10/21(水) 03:42:14.98

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

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

**NAME IS NULL** · 2015/10/21(水) 08:05:55.58

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

**NAME IS NULL** · 2015/10/21(水) 11:53:31.00

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

**NAME IS NULL** · 2015/10/22(木) 22:56:27.92

☆ 日本の核武装は早急に必須ですわ。☆
総務省の『憲法改正国民投票法』、でググってみてください。
日本国民の皆様方、2016年7月の『第24回参議院選挙』で、日本人の悲願である
改憲の成就が決まります。皆様方、必ず投票に自ら足を運んでください。お願い致します。

**NAME IS NULL** · 2015/12/11(金) 18:44:54.97

常に削除フラグを絞込条件に入れなきゃいけないくそ設計。

**NAME IS NULL** · 2015/12/12(土) 00:14:07.98

違う違うそこじゃない

**NAME IS NULL** · 2015/12/13(日) 23:05:09.17

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

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

**NAME IS NULL** · 2016/03/18(金) 16:51:41.96

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

**NAME IS NULL** · 2016/06/02(木) 14:34:16.25

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

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

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

**NAME IS NULL** · 2017/12/29(金) 12:14:46.57

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

YJJ4K2H9GU

**NAME IS NULL** · 2018/02/14(水) 13:40:52.44

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