リレーショナルデータベースで、参照整合性を維持しながらオブジェクトグラフからオブジェクトを削除するための最良の方法は何ですか?ある時点で、これが発生する必要があります。ソフト削除またはハード削除のいずれかを使用します。
たとえば、製品が削除された場合、その製品を含む注文が引き続き関連していること、またはさらにその製品を含む注文を含む請求書が引き続き関連していることを確認するための最良のアプローチは何ですか?
リレーショナルデータベースで、参照整合性を維持しながらオブジェクトグラフからオブジェクトを削除するための最良の方法は何ですか?ある時点で、これが発生する必要があります。ソフト削除またはハード削除のいずれかを使用します。
たとえば、製品が削除された場合、その製品を含む注文が引き続き関連していること、またはさらにその製品を含む注文を含む請求書が引き続き関連していることを確認するための最良のアプローチは何ですか?
基本的に3つの「標準ソリューション」があります。
解決策1
製品が必要です(請求書がそれを参照しているため、あなたの場合のように)。これは、データが有効であり、唯一の変更は「在庫切れ」または「ポートフォリオ外」になることを意味します。いずれにせよ、ビジネスプロセスでは、RMAの状況やIRS関連の問題などを処理する必要があることがよくあります。これは、製品を削除してはならないことを意味します。これは、DBデータモデルなどに反映する必要がある製品の単なる異なる「状態」です。
パフォーマンスに関心がある場合は、プロファイリングを行ってください...必要に応じて、多数の最適化オプションがあります...これらは通常RDBMSに依存し、1つの手法は「パーティション化」です。すべてのRDBMSには、柔軟性などが異なる独自のメカニズムがあります。 。
解決策2
データはまったく必要ありません...カスケード削除を実行して、それで完了します...
解決策3
履歴データのみが必要ですが、「将来のビジネスプロセス」でこのエンティティ(つまり製品)が再び必要になることはありません...この場合、一般的な解決策は、「アクティブ/生産的」でカスケード削除を実行する前にアーカイブテーブルを埋めることです。テーブル」。このスキームのわずかな変形は、必要な情報を「依存行」(あなたの場合は請求書)にコピーし、アクティブ/生産行(つまりあなたの場合は製品)を削除することです。
結論
複雑なシステムは多くの異なるビジネスプロセス/ユースケースを処理するため、上記のすべての手法を採用する傾向があります-それぞれが関連する特定のビジネスプロセス/ユースケースに依存する場所を持っています...
これが私が名前のない情報源から受け取った答えです。私はこれを言います、彼はかなり尊敬されています、そして敬意を表するために私は彼の名前を投稿するつもりはありません。
私はここで自分の答えを受け入れたり、賞金を迂回したりするつもりはありませんが、彼の答えを示しているだけです。
「フル機能のRDBMSを使用すると、「deleted_or_not」列でテーブルを分割できます。これにより、すべてのライブプロダクション行がコンパクトに保存されます。非推奨のデータをレポートに表示したくない場合は、次のように入力してください。完全なテーブルはcustomers_include_deleted_rowsなどのあいまいな名前であり、ほとんどのアプリケーションコードがクエリを実行するビュー「customers」(ライブ行のみを含む)を作成します。これは、もちろん、古いデータを保持することに何らかの価値があることを前提としています。 。」