削除フラグの要否について語るスレ [転載禁止]©2ch.net (34ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
5(5): 2015/10/19(月)18:03 ID:??? AAS
俺の考える削除フラグの代替案
■削除フラグを辞めて状態（status）を追加する
単純な有効/無効の切り替えならこれでOK
■会員が退会、社員が退職、商品が廃盤になる時は、履歴テーブルに移す
ただし、移す時は最低限の個人情報のみとする。
会員・社員なら名前、商品なら商品名。
これだけだと重複した名称も多いだろうから、個人特定に繋がらない（はず
■データの復元はしない
復元が必要な場合、削除フラグのように見せなくするか、
全く同一のテーブルをもう1つ用意するしか無い（DBMSによっては違うかも
省11
6(1): 5 2015/10/19(月)18:10 ID:??? AAS
削除フラグを使うか別の方法にするかの判断は1つしか無いと思います。
それは「後からデータを参照・復元する可能性がどの程度あるか？」です。
会員サービスなど不特定多数が触るシステムの場合は、
うっかりさんが多い可能性があるので、安易に物理削除は面倒になるかもしれません。
逆に社員管理や商品管理など自社内で操作する場合は、
自分たちがルールを守ればいいだけだから、>>5の方法が有効だと思われます。
あとは要件次第で設計を変更したりつけたりたりしていけばいいかと。
8(1): 2015/10/20(火)10:22 ID:??? AAS
>>5
いつまで個人情報にこだわってんだよ
10(1): 2015/10/20(火)10:46 ID:??? AAS
>>5
> ただし、移す時は最低限の個人情報のみとする。
> 会員・社員なら名前、商品なら商品名。
> これだけだと重複した名称も多いだろうから、個人特定に繋がらない（はず
どうしてこれにこだわるんだ？
削除フラグ（論理削除）に絡んだデータベース設計とは関係ない話。
商品情報に個人情報など関係ない。
16: 2015/10/20(火)11:50 ID:??? AAS
>>5
> ■削除フラグを辞めて状態（status）を追加する
> 単純な有効/無効の切り替えならこれでOK
なぜそれでOKなんだ？
21: 2015/10/20(火)13:14 ID:??? AAS
>>5
せめて、
手段1：〜〜〜
メリット：〜〜〜
デメリット：〜〜〜
手段2：〜〜〜
メリット：〜〜〜
デメリット：〜〜〜
という構成にしてくれませんか。
個人情報云々が無くなればなお良し。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.350s*