現実世界で完全な削除(DELETE)は存在しない

Webアプリケーションの概念の1つのCRUD処理

CRUD処理

-	-	-
C	CREATE	タレントを作成する
R	READ	タレントを閲覧する
U	UPDATE	タレントを更新する
D	DELETE	タレントを削除する

今回、着目したいのはDELETE、削除する処理。

注意しないといけないのは、完全に削除することは現実世界ではありえない
例えば、タレントが退会したという処理をおこなうときに安易にタレントをDELETEして完全に削除してしまうと、退会したという情報は取得できない。

現実を抽象化したデータを忠実に再現するためにはDELETEは実行しない方がいい。
タレントを安易に削除するというのは、タレントが複業クラウドを使っていたという事実を削除することに値する。

ではどうやって実装するか？

論理削除

データベースから直接データを削除せず、削除フラグまたは削除日時を更新して退会を表現。

users

id	name
1	たなか
2	さとう
3	おだ

-- 通常の削除(物理削除)
DELETE users  WHERE users.id = 3

-- 論理削除
UPDATE users SET deleted_at = '2021-06-25 06:43:21' WHERE users.id = 3

通常の削除(物理削除)

id	name
1	たなか
2	さとう

論理削除

id	name	deleted_at
1	たなか
2	さとう
3	おだ	2021-06-25 06:43:21

メリット

• 退会したユーザを取得するのが簡単

SELECT * FROM users WHERE deleted_at IS NOT NULL;

デメリット

• 表示時にWHERE句にフラグの確認が必要になる(バグの原因。アクティブなユーザを取得したい)

-- 削除したユーザまで取得してしまう、、、。
SELECT * FROM users;

• データが肥大化するため、パフォーマンスが落ちる

削除のタイミングで履歴テーブルに移す

INSERT INTO deleted_users SELECT users WHERE users.id = 3
DELETE users WHERE users.id = 3

deleted_users

id	name
3	おだ

users

id	name
1	たなか
2	さとう

メリット

• SELECTで論理削除を意識しなくてよくなる

-- ユーザだけ取れる
SELECT * FROM users;

デメリット

• 2つのテーブルを行ったり来たりする必要がある(めんどくさい、、。)
• 関係テーブルも履歴を作る必要があり、複雑になる

結論

正解はない。
削除(完全消滅)というのは現実世界に存在しない概念なので、DELETE処理を実装する際は注意！！
メリット・デメリットを考慮して実装する必要がある。

▼複業でスキルを活かしてみませんか？複業クラウドの登録はこちら！
https://talent.aw-anotherworks.com/?login_type=none