Mysqlは多種の論理削除方案を実現する

Mysqlは多種の論理削除方案を実現する

新規論理削除フィールド方式

マルチdeleted値

deleted:0は削除されていないことを表し、削除時にdeletedをタイムスタンプUNIX_に割り当てます.TIMESTAMP(NOW())

バックアップテーブル方式

を採用
最近会社のプロジェクトをする时、表のロジックの削除に対して、他の同僚と异なる意见が现れたので、いくつかのblogを调べて、自分の実际の情况を结び付けて、再び笔记をして、后で调べるためです.実際のプロジェクト開発では、いくつかのビジネスデータに対して、一般的に物理的に削除する方法は採用されません.結局、データは貴重なので、論理的に削除する方法もあります.一般的な論理削除方法は以下の通りである:1.関連するテーブル構造の論理削除フィールドdeleted 0が追加され、削除されていないことを示し、1が削除されたことを示す(現在最も一般的な方法;2.バックアップ・テーブルを使用して、削除するデータをバックアップ・テーブルに書き込み、プライマリ・テーブルのデータを削除する.以下、2つの異なる方法の使用例について、その利点を分析する.
新規論理削除フィールド方式
フィールドにdeleted:0を設定すると、削除されていません.1は削除されています.以下の説明は、Artifact表で説明します.この表のproject_idおよびnameはartifact表のUnique KeyおよびUK(project_id,name)です.次の図に示すように、artifact_02は削除されたが、テーブル構造が連合インデックスを設計しているため、このレコードも追加できなくなるため、この場合は削除を満たすしかないが、同じデータの再追加は実現できない.だから論理削除のニーズに合わないシーンもありますが、改善点はありますか?答えはもちろんあります.
id
project_id
name
create_user
deleted
1
project001
artifact_01
xiaoma
0
2
project002
atifact_02
xiaoma
1
4
project003
phone
xiaoma
0
マルチdeleted値

0:削除として、その他の値は削除を表し、以下の表:

id
project_id
name
create_user
deleted
1
project003
phone
xiaoma
0
2
project003
phone
xiaoma
1
4
project003
phone
xiaoma
2
この方式はUnique Keyを維持することができますが、deletedの衝突が多いので、deletedの累積を保証する必要があります.それはもっと方法がありますか.次は上の改良版です.
deleted:0は削除されていないことを表し、削除時にdeletedをタイムスタンプUNIX_に割り当てます.TIMESTAMP(NOW())
実はゼロ以外の値を削除はいのタイムスタンプに変更することです.このようなメリットは、現在の削除データの時間を記録できることです.また、特定の時点でのレコードの検索と遡及にも便利です.
id
project_id
name
create_user
deleted
1
project003
phone
xiaoma
0
2
project003
phone
xiaoma
1573631978
4
project003
phone
xiaoma
1573631943
バックアップ・テーブル方式の採用
削除するたびにバックアップテーブルにデータを書き込み、元のレコードをJSON形式で完全に保存してから削除するのが実現原理です.やはりartifact表を例に挙げます.ここで論理削除を実現するには、削除するデータを格納するためにartifact_bankend表を新規作成します.artifact表のデータは以下の表のように、idが2の記録を削除したいのですが、私がしなければならないことは、まずartifact表のidが2のこの表のデータcopyをartifact_bankend表に、artifact表のデータを削除することです.
id
project_id
name
create_user
1
project001
artifact_01
xiaoma
2
project002
atifact_02
xiaoma
4
project003
phone
xiaoma artifact_bankend表:artifact表のデータをartifact_bankend表に書き込む.削除時間を格納するdeletedフィールドが追加されました.
id
project_id
name
create_user
deleted
2
project002
atifact_02
xiaoma
2019-11-14 15:14:45
削除後のartifact表のデータは次のとおりです.
id
project_id
name
create_user
1
project001
artifact_01
xiaoma
4
project003
phone
xiaoma
利点:元のテーブルには削除されたデータが含まれていないため、クエリーの効率が低下します.欠点:実現が面倒で、論理的に削除する必要があるテーブルごとにバックアップテーブルが必要です.
https://cloud.tencent.com/developer/article/1531915