何か（SQLとDB）を削除する必要がありますか？
私は興味があります、私は何かを削除する必要がありますか？現在、私は（私自身のために）ユーザーをサブスクライブできるサイトを構築しています。このサイトでは、ユーザーがコンテンツをアップロードするたびにメッセージを受け取ります。
またはコメント、スレッドがあり、誰かがあなたのコメントに直接コメントを書いた場合、あなたはそう言っているメッセージを受け取ります。それらを削除する必要がありますか、それとも単に非表示にする必要がありますか？
各サブスクリプションには3つの（64ビット）intがあります。 id、commentId、recipientId。 commentIdを介してコメントテーブルを見ると、誰があなたに書いたかを知ることができます。 deleteを使用しない場合、ステータス（表示、非表示/削除）を示す4番目のintが表示されます。
それらを残すか削除する必要がありますか？それらを削除する必要がある場合、なぜですか？リクエストに応じて削除しなければならない個人ユーザーがいる場合はわかりますが、それ以外の場合は削除する必要がありますか？
どのSQLDBを使用するかわかりません。
-編集-
みんなありがとう。今は、生成できるもの以外は何も削除しません。そのようなサブスクリプションのことについて。
私が働いている会社は、特定の規制された業界の人々にソフトウェアを提供しているので、一般的に私は「削除しないでくださいanything "」という態度をとっています。代わりに、情報を削除済みとしてマークし（または、テーブルのアーカイブバージョンに移動し）、誰がいつ「削除」したかを記録します。
本当にものを削除する唯一の理由は
- スペースが不足している場合（ただし、最近はディスクが安価です）
- 効率のために（ただし、データ構造のインデックスが適切に作成されていて、断片化が不十分でない場合、これによる違いはほとんどありません）
- 法的な理由で（地域のデータ保護法によっては、誰かの詳細を削除するように求められた場合、またはコンテンツ自体が何らかの法律に違反している場合は、遵守する必要があります）
ユーザーが誤って有用なものを削除して、それを取り戻すことができた場合、ユーザーは実際には何も削除されないことに感謝するかもしれません。また、以前にサイトに貴重な情報を提供したことのある動揺したユーザーが、ヒッシーフィットを投げて、復讐のためにすべての投稿を削除した場合、削除を簡単に撤回できます。
さらに非常に重要な点が1つあります。利用規約で、ユーザーが情報を表示できなくなったときに情報が実際に削除されない可能性があることを明確にし、ルートを提供する必要があります（「x @ xxにメールを送信して、行われる」）彼らが実際にデータを削除するために、彼らは関連する法律の下で削除を要求する権利を持っています。
通常、今日の最新のディスクサイズとIOパフォーマンスは、スペースを節約したり維持したりするためにレコードを削除する必要がないことを意味しますパフォーマンス。通常、レコードの「レコードが削除されました」フィールドは、監査証跡を使用してレコードを削除済み（または他のステータス）としてマークできます。
一部の業界では、規制上の理由から「トランザクション」データを削除しないことが義務付けられています。あなたはこれをする必要があるかどうかをすでに知っているでしょう。支払い情報がある場合は、通常、データを7年間保持する（またはデータを利用できるようにする）必要があります（英国の会計法）。
他の目的のために、実際にはデータを物理的に削除する正当な理由があります。
そこにない場合は発見できません。
情報公開法（英国）では、データが検出可能である場合、そのデータはすべての検索の範囲に含まれると規定されています。これには、「ソフト削除」レコードと履歴バックアップが含まれます。
一部のシステムでは、古いレコードをパージし、「非常に多くの」月後に古いバックアップテープ/ファイルを再利用/破棄して、FOI要求に使用できないようにします。 （数年前にさかのぼり、アーカイブバックアップから何百もの古いメールボックスを復元する必要があるFOI要求を処理するには、非常にコストがかかります）。
これは、OPERATIONALバックアップとは異なります。災害が発生した場合に復元できるように、バックアップを保持しています。また、紙ベースと電子メディアの両方で保管しなければならない「レコードストア」があり、そのストアに電子メールなどをコピーします。
何かを削除してはいけない理由：
- 後で欲しいかもしれません
何かを削除する必要がある理由：
- 許可されていない人がそれを再び読み取れないようにする必要があります（たとえば、保存されているクレジットカード番号：消去すると侵入者はそれを取得できません）
- あなたは、あなたから情報が要求されないようにしたい（例えば、情報公開法の要求を通じて）
- スペースまたは速度の理由から、データサイズを小さく保つ必要があります（適切なインデックス作成とパーティション分割は速度の問題に役立ちます）。
- 法律（プライバシー法など）により削除する必要があります。
これは常にトレードオフですが、データを大量に保持することの法的な意味合いは重要です。プライバシーとセキュリティは、最近見過ごされがちなものです。データセットが巨大でない限り、実際のデータベースパフォーマンスではデータを削除する必要がない場合があります。数百万の行と数十の列を持つテーブルでも、適切にパーティション分割し、クエリで常に適切なパーティションを使用するようにすれば、削除する必要がない場合があります。裁判所命令またはFOIA保存データの要求）については、あなただけがそれについてどのように感じ、顧客がどのように感じるかを決めることができます。まさにこの理由：私のデータは米国に保存されており（私はカナダにいます）、米国の代理店は削除されたメールにもアクセスできる可能性があります。
また、プライバシー、セキュリティ、およびFOIAの法律は国によって異なります。運用するすべての国で、これらの法律に注意する必要があります。サーバーがすべて1つの国にある場合など）それは外国法の適用範囲を制限しますが、そうではないかもしれません。データが機密である場合は弁護士に相談してください。
あなたが本当に自問しなければならない質問はこれです：データを保持するコスト（ストレージコストの増加、削除可能なデータを保持する責任）はデータを削除するコスト（削除クエリを書くための工数）よりも安いですか？保持する必要のあるデータを削除する責任、および削除クエリの実行によるダウンタイムまたはパフォーマンスの低下の可能性）？どちらか安い方を選んでください。
オフラインでのアーカイブやデータの削除が見られるケースの1つは、OLAPクエリを実行してデータを要約し、それを要約テーブルに格納する場合です。
毎月のウェブサイト統計は、この良い例です。 2009年6月に多数のページビューを生成した後は、それが変わることはありません。また、1年分のログをスキャンして完全にオンラインのレポートを生成するよりも、サマリーテーブルからすべてのページビューを追加してから、今月のオンライントランザクションを含むテーブルをスキャンする方が高速です。 。
私の場合は、オンラインテーブルを「2009年6月」にコピーし、サマリークエリを実行してデータをサマリーテーブルに保存してから、コピーしたオンラインテーブルをアーカイブしてから、すべてのエントリを削除します。オリジナルのオンラインテーブル。しかし、私もやや妄想的です！
一般に、OLAPを使用して、その時点から静的なデータに対して要約を生成する方が効率的な場合は、古いデータをアーカイブ/削除できます。それ以外の場合は、削除を使用します。私の一般的に広範なアクティビティロギングシステムとの関係整合性を壊さないようにシステムにフラグを立てます。
私の本能は、何も削除しないことです。いつ必要になるかわかりません。何らかの理由で作業テーブルからデータを削除する必要がある場合は、アーカイブテーブルに移動する傾向があります。
そうは言っても、それがあなた自身の使用のためのデータであり、古いデータを見る法的理由があるとは考えられない場合、これはやり過ぎかもしれません。あなたはあなたのアプリケーションについてそれほど多くを語っていませんが、あるユーザーが別の使用が彼らを解放したという理由で古いデータを見ることを要求することができますか？
JR
削除するかどうかは、利用可能なリソースの量と収集するデータの量によって異なります。私は以前、削除が許可されていないプロジェクトに取り組んできました。これは、すべてのデータ項目が開始日と終了日を取得することを意味していました。データ項目は、この期間中、前ではなく、後ではなく有効になります。したがって、終了日を今日に設定することで、何かを「削除」できます。
残念ながら、これは、選択するすべてのデータ項目について、この期間で現在の日付を確認する必要があることも意味します。 SQLの場合、これにはクエリに追加の条件が必要になります。
実際、事態をさらに悪化させるために、編集を無効にすることも検討できます。データ項目が編集されたら、終了日をnowに設定し、同じキーと変更を加えて新しいデータ項目を作成するだけです。そうすれば、膨大なデータのコレクションを収集できますが、それは非常に歴史的であり、何も削除されません。この場合、開始日/終了日には時間コンポーネントも含まれている必要があります。 （そして、時計が1時間逆になっている夏の間は心配する必要があります。）しかし、基本的に、システムは新しいアイテムを挿入するだけで、何も変更または削除しません。
データを永久に保存する価値があるかどうかを判断する必要があります。ディスクは安いと誰もが言っていますが、それだけではありません。ストレージソリューションと環境によって異なります。
SANでファイバーチャネルディスクを使用していて、ディスクスペースが不足している場合、アレイのスペースが不足しているために別のディスクアレイを追加する必要がある場合は、もう安くはありません。
あなたの場合、大量のデータを保存しているようには見えず、ディスクスペースは問題ではないかもしれませんが、10年間のデータの関連性はどの程度ですか？
もう1つ考えるべきことは、ディスクスペースだけでなく、全体的なパフォーマンスです。履歴データを別のテーブルまたは別のデータベースに保存することをお勧めします。このようにして、メンテナンスなどが少なくなります。パーティション化など、履歴データをアーカイブする他のソリューションがありますが、そのデータが定期的に使用されない場合、なぜより複雑なものを実装するのですか？
私は過去6年間大規模なデータベースで作業してきましたが、500 000 000レコードのテーブルがある場合、インデックス作成戦略は非常に重要です。 :)クエリがインデックスシークを使用しているが、インデックスに必要なすべてのデータが含まれていない場合、インデックスで見つかったすべてのレコードに対してクラスター化インデックスルックアップが使用されます。テーブルの10％を取得すると、最終的に50 000 000のクラスター化インデックスルックアップが作成されますが、これは決して安価ではありません。それはあなたにお金はかかりませんが、それはあなたにパフォーマンスを犠牲にします。
/HåkanWinther