MAIL
レコード/テーブル/フォルダ削除の実態と、データベースファイルサイズ削減の手順
まずはレコード削除とデータベースファイルサイズ削除の違いについて見てみましょう。
レコード削除：
・DELETE文やプリザンターの「ごみ箱を空にする」操作で行う処理。
・データはテーブルから論理的に削除されます。
・ただし、データベース内部で確保していた領域はすぐには解放されず、ファイルサイズ（ディスク上の物理サイズ）はそのままです。
👉 つまり「削除済みマークがついただけ」「空きスペースとして再利用可能」な状態。
データベースファイルサイズ削減：
・データベースファイルそのものを物理的に縮小する処理。
・データベースごとに専用のメンテナンスコマンドが必要。(後述参照）
・メンテナンスコマンドを実行すると、空き領域を詰め直してファイル自体を小さくできます。
👉 「PCのハードディスクをデフラグして物理容量を解放する」イメージに近いです。
例えるなら：
レコード削除
📒ノートのページはそのまま残っているが、内容だけが消えて白紙のスペースができる。
→ データベースでは「中身のレコードは消えるが、ファイルサイズ（ページ数）は変わらない」
データベースファイルサイズ削減
📒不要なページそのものを破り捨てることで、ノート自体が薄くなる。
→ データベースでは「空き領域ごと縮小して、ファイルサイズ自体が小さくなる」
上記を踏まえ、プリザンター上で削除を行った際の挙動について確認しましょう。
■ レコード削除の挙動
1. レコードを削除すると、ごみ箱に移動します。
- データベース上では「Results → Results_deleted」へ移動（期限付きは「Issues → Issues_deleted」）。
2. ごみ箱からレコードを削除すると、データベース上からも完全に削除されます。
ポイント：プリザンター画面上で「消えた」段階では、まだ*_deleted側に残っている可能性があります。完全に消すにはごみ箱を空にする（=*_deletedからも削除）ことが必要です。
■ テーブル削除の挙動
1. テーブルを削除すると、ごみ箱に移動します。
- データベース上では「Sites → Sites_deleted」へ移動。
- テーブルに登録されているレコードも「Results → Results_deleted」（期限付きなら「Issues → Issues_deleted」）へ移動。
2. ごみ箱からテーブルを削除すると、テーブル自体はデータベースから消えます。
- ただしテーブルに登録されているレコードは Results_deleted（期限付きは Issues_deleted）に残り、プリザンター画面からは見えません。
ポイント：「テーブルを完全削除」しても、レコードの削除履歴が*_deleted側に残る点に留意してください。
■ フォルダ削除の挙動
1. フォルダを削除すると、フォルダと配下のテーブルがごみ箱に移動します。
- データベース上では「Sites → Sites_deleted」へ。
- 配下テーブルも「Sites → Sites_deleted」へ。
- テーブルに登録されているレコードは「Results → Results_deleted」（期限付きは「Issues → Issues_deleted」）へ。
2. ごみ箱からフォルダを削除すると、フォルダとテーブルはデータベースから消えます。
- ただしテーブルは Sites_deleted に、レコードは Results_deleted（Issues_deleted）に残り、プリザンター画面からは見えません。
ポイント：フォルダ単位の削除は影響範囲が広く、*_deleted側に多くのデータが溜まりやすい点に留意してください。
■ レコード・テーブル・フォルダを確実に消す3つの方法
方法1：各テーブルでレコードを完全削除（ごみ箱も空に）してから、テーブルやフォルダを削除する
- この順序なら、レコードもテーブルもデータベース上から削除されます。
方法2：プリザンターのAPIで レコード一括削除 を実行する
- PhysicalDelete を指定したAPIにて、各サイトのデータを一括削除できます。大量データ時や運用自動化に有効です。
方法3：BackgroundService で定期的にごみ箱の削除を実行する
- DeleteTrashBox のパラメータを有効化にし、指定した期間（DeleteTrashBoxRetentionPeriodの日数）経過後にごみ箱の中身を毎日定時刻に削除します。
■ ごみ箱を空にしてもデータベースファイルサイズが小さくならない理由と対処
プリザンターのごみ箱を空にしても、データベースファイルサイズは自動で小さくなりません。データベースごとの性質に応じてメンテナンスが必要です。
✅ PostgreSQL
- 削除（または更新）された行は、物理的には直ちに消えず「無効（dead tuple）」として領域内に残ります。
- 実際にディスク上の保存領域（テーブルファイル）を小さくするには VACUUM FULL の実行が必要です。
👉 運用のコツ
- VACUUM FULLは排他ロックが発生しやすく、処理中は性能や可用性に影響します。業務時間外に計画実行することを推奨します。
- まずは通常のVACUUM/AutoVacuumで内部再利用を促し、ディスク上の保存領域の削減（物理縮小）が必要なタイミングのみVACUUM FULLを検討するのが現実的です。
- 実行前のバックアップ取得、対象テーブル選定（肥大化が著しいものから）、メンテナンス時間の確保がポイントです。
✅ SQL Server
- 削除や更新で空いた領域はデータベース内部で自動再利用されます。
- 物理ファイルのサイズ（=データベースファイルサイズ）自体を小さくしたい場合に限り、DBCC SHRINKDATABASEを計画的に実行します。
👉 運用のコツ
- 頻繁な縮小は断片化やその後の自動拡張を招き、かえってパフォーマンス低下を引き起こすことがあります。やむを得ない場合のみ、計画的に実行しましょう。
- 実行前のバックアップ、実行後のインデックスメンテナンス（再構築/再編成）も検討してください。
まとめ
いかがでしたか。
プリザンターの「削除」は、まず*_deletedへの移動であり、即座にデータベースファイルを縮小するわけではありません。
レコード/テーブル/フォルダでの削除の実態を把握し、完全に消したい場合は「レコード完全削除 → テーブル/フォルダ削除」の順序を徹底しましょう。
または、APIを使った一括削除、BackgroundServiceによるごみ箱の定期的な削除も活用しましょう。
データベースファイルサイズの縮小はデータベースの特性に依存します。PostgreSQLならVACUUM FULL、SQL Serverなら必要時のみDBCC SHRINKDATABASEを計画的に。
削除ポリシーとメンテナンス計画をセットで整えることが、安定運用とコスト最適化の近道です。
弊社では、プリザンター導入・活用に関して以下のサービスをご提供しています。
・年間サポート
・各種書籍
・帳票出力（Excel/PDF）支援パック
プリザンターの導入から開発・運用をあらゆる角度から全力サポートいたします。
ぜひお気軽にご相談ください！
☆☆☆
サービスの説明などをご希望の方は【 問い合わせフォーム 】よりお気軽にお問い合わせください。
☆☆☆
削除＝容量減ではない！ごみ箱とデータベースファイルサイズの関係
こんにちは、シーイーシーカスタマサービスの森山です。
プリザンターで不要となったフォルダやレコードを削除した際に、「ディスク使用量が減っていない」と疑問に思ったことはありませんか？
この疑問は、プリザンターの削除の仕組みと、データベース（PostgreSQL/SQL Server）のファイル管理の違いを理解するとスッキリ解消します。
まずはプリザンターの構造とデータベース上の対応を整理しましょう。
■ プリザンター上の構成（サンプル）
- フォルダ ＞ 記録テーブル ＞ レコード
■ データベース上のテーブル対応
- フォルダ＝Sites
- 記録テーブル＝Sites
- レコード＝Results（期限付きテーブルの場合は Issues）
- ごみ箱＝各テーブル名＋_deleted（例：Sites_deleted、Results_deleted、Issues_deleted）
※プリザンターでは、フォルダやテーブルといった「入れ物」全体を『サイト』として扱います。
このため、データベース上では「フォルダ」も「テーブル」も同じ「Sites」テーブルで管理されます。
ポイントはプリザンター上での「削除」操作は、まず「ごみ箱（*_deleted）」への移動であり、即座にデータベースファイルサイズを縮小しないことです。
ここを明確にしたうえで、次章でレコード/テーブル/フォルダ削除の挙動を具体的に確認し、最後にデータベースファイルサイズ削減の正しい手順をまとめます。
なお、本記事ではデータベース容量の話題を扱う際、混乱を避けるために「データベースファイルサイズ（ディスク上の物理サイズ）」と表記します。