3

だから私はRailsアプリを構築しているクライアントを持っています....私はPostgreSQLを使用しています。

彼はレコードを削除するよりも非表示にすることを好むとコメントしましたが、これについて聞いたのはこれが初めてなので、皆さんの考えを聞いてもらいたいと思いました.

テーブルの削除は最終的にテーブル インデックスの大混乱につながり、クエリに予想以上の時間がかかるため (挿入や更新よりもはるかに悪い)、削除するよりも非表示にしたいと考えています。これは、サイトの初期段階では問題にはなりません (時間が経つにつれて指数関数的に悪化します) が、「日常的な」Web アプリケーション機能の一部として (まだ) 何も削除しないだけで、簡単に遭遇しない問題のように思えます。データの最適化とメンテナンス プロセスの一環として、後で削除をいつでも処理し、そのプロセスで (まだ決定されていない) スケジュールに基づいてテーブルを再インデックス化できます。

私が構築したすべての Rails アプリで、レコードが削除されてインデックスに影響を与えるという問題が発生したことはありません。

何か不足していますか？これは以前から存在していた問題ですが、最新の RDBMS 製品では修正されていますか?

4

3 に答える 3

1

レコードを削除しないその他の理由。

  1. 削除する行を参照するデータベース内の他のさまざまなテーブルを介して削除をカスケードすることを心配する必要はありません

  2. すべてのデータが役に立ちます。デバッグと監査が容易になります。

  3. 必要に応じて簡単にロールバックできます。

于 2013-08-31T03:16:55.627 に答える
0

テーブルに削除された列を作成し、その列にインデックスを付けないでください。

そのレコードをdeleted = 1またはdeleted = oで更新する場合、データのみを書き換える必要があり、インデックスを更新する必要がないため、IO読み取りとIO書き込みが大幅に節約されます

これは、B ツリー インデックスを使用するすべての最新の RDBMS に当てはまります。Bツリーは検索には非常に優れたアルゴリズムですが、更新と削除には適していません。ノードのノードを挿入または更新したり、ツリーからメモを削除したりするために必要なIO読み取りとIO書き込みの数が多いためです。テーブルを「オーバーインデックス」

このようなレコードを「削除」します

UPDATE table SET deleted = 1 WHERE id = 1 -- if deleted not is indexed assuming id is index as an primary key this also should be fast

レコードが削除されたかどうかを確認する

SELECT * FROM table WHERE id = 1 and deleted = 1 -- assuming id is index as an primary key this also should be fast

レコードが削除されていないかどうかを確認する

SELECT * FROM table WHERE id = 1 and deleted = 0 -- assuming id is index as an primary key this also should be fast
于 2013-08-31T12:56:06.490 に答える