データベース内のデータを削除する必要がありますか？
私はデータベースに不慣れで、基本的な概念を理解しようとしています。データベース内のデータを削除する方法を学びました。しかし、私の友人の1人が、データベース内のデータを削除してはいけないと言っています。むしろ、不要になった場合は、単にそれをマークするか、「未使用」としてフラグを立てることをお勧めします。
本当？もしそうなら、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サイトセッションデータと古いログ情報。それらを永久に保持することにはまったく意味がありません。
しかし、いつものように、正確な答えは実際には特定の状況に依存します。
ほとんどの場合、将来必要になる場合に備えてデータを保持する必要があります。あなたが働いている企業は、履歴データを見て、特定の方向にcomapanyを導く決定に基づいて決定することができます。
各テーブルに「Date_Time_Removed」列を追加してから、行を物理的に削除する代わりに、行が仮想的に削除された日時を設定します。次に、ストアドプロシージャまたはSQLで、 'Date_Time_Removed'列を考慮に入れます。 date_time_removedがnullであるtable1からblahを選択します
もちろん、データベースに誤って追加された行は、特にテストデータは完全に削除する必要があります。
すべての正当なデータを保持することにより、将来の倉庫保管にデータベースを使用するオプションも必要になります。
他の状況とは別の状況として、データが削除されたが、データベースで実行された操作のログ（削除を含む）が長期間アーカイブに保存されている場合があります。これの主な範囲は、過去の日付へのロールバックシステムの実装ですが、何らかの方法で削除されたデータ（データベースから削除されますが、アーカイブに保存されます）を保存するためにも使用できます。
削除されたデータのアーカイブを保存することは、それほど大きな問題ではありません。大企業は、コードのバージョンやその他多くの情報（技術関連以外のものについて話さないこと）を保存することもあるので、結局、大規模なデータを保存することは、彼らにとって通常のことです。
私はこれが登場した数年前から外国為替申請に取り組んでいます。アプリケーションが長年にわたって収集したデータは、パフォーマンスに影響を与えました（指数関数的など）。
コードで可能なことを行った後、1年以上経過したデータをアーカイブすることを経営陣に提案しました。彼らはコンセプト（法的問題）を検証し、幸いにも私たちはそれを行うことができました。そのため、削除しましたが、データをアーカイブして、企業がレポートなどを実行できるようにしました。