⇧ う～む、骨折とかするのは、相当な外力が加わっているということなのだろうか？
トランザクション系のテーブルの論理削除フラグのメリット・デメリット
これまで携わってきたプロジェクトだと、トランザクション系のテーブルに「論理削除フラグ」の属性（カラム）が存在していたので、とりあえずトランザクション系のテーブルには入れておくものなのかと思って、メリット・デメリットを意識してこなかったので、整理してみる。
ちなみに、テーブルで不要になったレコードを削除する際に、
- 物理削除
→レコード自体を削除する - 論理削除
→レコード自体は削除せず、状態を持たせる
の2つの考え方があって、「2. 論理削除」の方法で必要になるのが「論理削除フラグ」で、レコードは残したまま、
- 未削除
- 削除済
フラグでレコードの状態を表わすことで、削除された状態なのか、削除されていない状態なのかを管理すると。
ネットの情報によりますと、
⇧ 何やら、マイクロサービスアーキテクチャ以外だと、圧倒的に「論理削除フラグ」を採用することの弊害が大きいという意見が多そうではある。
リトライ処理とトランザクション系のテーブルの論理削除フラグ
とは言え、アプリケーション側でリトライ処理などでテーブルの更新系（INSERT、UPDATE、DELETE）が絡む場合を考えてみる。
ちなみに、リトライ処理については、
⇧ 上記サイト様がまとめて下さっています。
で、リトライ処理などでテーブルの更新系（INSERT、UPDATE、DELETE）が絡む場合で、テーブルのDELETEが関わるケースにおいて「論理削除フラグ」があれば、動作確認などする際にデータをすぐに戻せるというメリットはあると。
ただし、動作確認を優先して「論理削除フラグ」を採用した場合、データの整合性に影響が出て運用で苦しむことになると。
う～む、テーブル設計、難しいですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
