データベース内のデータを削除する必要がありますか？

私はデータベースが初めてで、基本的な概念を理解しようとしています。データベースのデータを削除する方法を学びました。しかし、私の友人の一人が、データベースのデータを削除してはいけないと言った。むしろ、不要になったら、単にマークするか、「使用していない」というフラグを立てることをお勧めします。

本当？もしそうなら、IBMのような大企業は100年以上にわたってどのようにデータを処理しますか？

これらすべてのものと同様に、答えは「依存する」です。

ユーザーがデータを戻す可能性が高い場合、友人は正しいです。レコードを「削除済み」としてマークするだけで本当に削除するわけではありません。これにより、ユーザーが気が変わったときにデータを回復できます。

ただし、削除されたデータが特定の期間（たとえば1年）以上経過している場合、ライブテーブルから実際に削除し、アーカイブテーブルに保存するか、ユーザーが必要に応じてバックアップすることもできます。戻ってきた。この方法で、データの量（ライブおよび最近削除された）を最小限に保つことができます。

ただし、データが一時的なものであるか、簡単に再作成される場合は、データを実際に削除することもできます。

削除する必要があるデータのクラスが1つあります。これは、ユーザーがこれ以上保持することを望まない個人データです。これを必須要件とする現地の法律が存在する場合があります（EUなど）（Gavinに感謝）

同様に、データを削除しないように要求する規則がある場合があるため、何かを決定する前に、法を順守するために必要なことを規制当局に確認してください。

これは実際、多くの企業にとって重大な問題です。どのデータが実際に使用されているかを明確に判断する方法はないため、データはデータベースに置かれます。データの削除とアーカイブは、すべての大規模システム設計の一部である必要がありますが、めったにありません。ほとんどの企業は、システムを変更し、現在のデータを識別してそれらのレコードを新しいシステムに移行するまで多大な労力を費やすまで、より大きなディスクを購入し、クエリとインデックスを微調整してパフォーマンスを維持します。

はい、データベースからデータを削除する必要がありますが、多くの場合、いつ何を伝えるのは簡単ではありません。

これにはすでに「状況に依存する」という非常に要約された多くの良い答えがありますが、私はそれらに何も追加することはできません。

言及されていないが、言及されていないことの1つは、シーケンスまたはAUTO_INCREMENTシステムによって生成された主キーを決して再利用してはならないということです。

そのようなシステムによって主キーが割り当てられたアイテムを削除すると、削除されたデータによって主キー列にギャップが残ります。追加された新しいアイテムにそれらのギャップを再割り当てしたり、さらに悪いことに既存のデータをシャッフルしてギャップを削除する新しいIDを付与したりする大きな誘惑がありますが、そうすると問題が発生しますキーをそのままにしておけば、対処する必要はありません。

消耗品の並べ替えを管理するためのプリンターのデータベースを保持しているとします。古いレーザープリンターであるプリンター13は、経済的な修理を超えて故障するため、廃棄します。一方、無関係な理由で、誰かが倉庫でバーコード印刷を行うために新しいサーマルプリンターを注文すると、そのプリンターはプリンター13の交換前にたまたま到着します。管理者はその新しいプリンターをデータベースに記録します。 IDをリサイクルしている場合、新しいサーマルプリンターにはIDとして13が割り当てられます。

今、誰かがプリンタ13のインクがほとんどなくなっていると言います。プリンタ13はレーザープリンタであるため、データベースで調べる必要はなく、トナーカートリッジを注文します。プリンタ13はレーザープリンタではなくなったため、実際にサーマルインクパックを注文する必要がありました。トナーカートリッジが届くと、プリンタのインクの補充が間違っているため使用できなくなり、バーコードを印刷できなくなり、発送待ちの注文を発送できなくなります。

さらに悪いことに、プリンタ13を削除し、ギャップを埋めるためにその後に来るすべてのプリンタをシャッフルするとどうなりますか？プリンター14（いくつかの老朽化した古いドットマトリックス）はプリンター13になり、プリンター15はプリンター14になります。

すべてのプリンタにはラベルが付いているため、データベースと相互参照できますが、すべてのラベルは古くなっています。巡回し、ビジネス内のすべてのプリンター（数百に達する可能性があります！）を見つけて、ラベルを付け直す必要があります。それは時間の効果的な使用ではありません。また、それはエラーが発生しやすいプロセスでもあり、それが完了しない場合はどうなりますか？誰かが電話をかけて、プリンター14が故障しており、緊急に修正する必要があると言ったので、調べてみると、プリンター14がレセプションのインクジェットプリンターであることがわかります。IDをシャッフルしたからこそ、実際に緊急に修正する必要があるのは実際にはドットマトリックスプリンターです。この問題で電話をかけた男はぶら下がっていますが、受付には壊れていないプリンターを修理するために電話をかけたことのない技術サポートの男がいます。

自動インクリメントシステムによって割り当てられたIDは永続的なものと考える必要があります。IDは、IDが参照しているものが存在しなくなっても、不変で再利用できません。一部の人々は、IDが不足することを心配する必要はないと主張しますが、32ビットシステムと署名されたIDであっても、利用可能なIDは20億ほどあります。ID列を符号なしにすることができる場合、これは40億に倍増し、64ビットシステムでは、使用可能なIDの数は空の星の数より文字通り大きくなります。IDを使い果たすことはありません。

すでに多くの良い答えがあります。まだ誰も言及していない状況を1つだけ追加します。

機密データ。ユーザーが削除した場合は、実際に削除した方が良いでしょう！

頭に浮かぶ非常に一般的な状況の1つは、パスワードの変更/リセットです。データベースに古いパスワード（ハッシュ化、ソルト化など）を保存したくないでしょう。ユーザーが他のサイトで古い（および悪い）パスワードを使用している可能性があります。

また、特定の種類のデータを保存できる期間に関する法律については、当然のことながらソフト削除は実行されません。実際に削除する必要があります。

だから私は自問します：データが削除されたと信じさせるとユーザー（または他の誰か、例えば政府）は怒っていますか？実際にはまだ持っており、いつでも復元できますか？

通常、データベース内のユーザーデータは削除しません。フラグを非表示にします。多くの場合、ユーザーが何かを誤って削除し、簡単に交換する必要があります。また、関連データの参照整合性を保持するのにも役立ちます。これは、小規模から中規模のデータベースで機能します。この決定によってパフォーマンスが大きく影響を受けるシステムでは、アーカイブテーブル、自動バックアップなどの特別な方法で処理されます。

期限切れのWebサイトセッションデータや古いログ情報など、必要に応じてバックエンドデータを破棄します。それらを永久に保持する意味はまったくありません。

しかし、いつものように、正確な答えは本当に特定の状況に依存します。

私はこれが出てきた数年の間、外国為替アプリケーションに取り組んでいます。アプリケーションが長年にわたって収集したデータは、パフォーマンスに影響を与えました（指数関数など）。

1年以上前のデータをアーカイブするために管理部門に提案したコードの面でできることを行った後。彼らはコンセプト（法的問題）を検証し、幸運にもそれを行うことができました。そのため、削除しましたが、データをアーカイブし、ビジネスが引き続きレポートを実行できるようにしました。

ほとんどの場合、将来必要になる場合に備えてデータを保持する必要があります。あなたが働いているビジネスは、特定の方向に会社を導く決定に基づいて、履歴データを見ることができます。

「Date_Time_Removed」列を各テーブルに追加し、行を物理的に削除する代わりに、行が仮想的に削除された日付と時刻を設定する必要があります。次に、ストアドプロシージャまたはSQLで、 'Date_Time_Removed'列を考慮します。たとえば、date_time_removedがnullであるtable1からblahを選択します。

もちろん、誤ってデータベースに追加された行、特にテストデータは永久に削除する必要があります。

すべての正当なデータを保持することにより、将来の倉庫保管にデータベースを使用するオプションも必要になります。

提示された他の状況とは別の状況として、データが削除されますが、データベースで実行された操作のログ（削除を含む）は長期間アーカイブに保存されます。これの主な範囲は、過去の日付へのロールバックシステムの実装ですが、何らかの方法で削除されたデータ（データベースから削除されますが、アーカイブに保存されます）の保存にも使用できます。

削除されたデータのアーカイブを保存することは、それほど大きな問題ではありません。また、大企業はコードのバージョンと多くの情報（非技術関連のものについては言及しない）を格納する場合があるため、最終的には大きなデータを格納することは彼らにとって普通のことです。