データベースからレコードを削除するときのベスト プラクティスは何ですか?
たとえば、このオンライン予約ツアー アプリケーションを持っているとします。
レコードを削除するツアー テーブルがありますが、ツアー テーブルは予約テーブルと顧客テーブルにもリンクしています。ここで、レコードの削除を許可するか、アーカイブなどを示すフラグのようなフィールドが必要です.
ベスト プラクティスとは
よろしく、ティー。
データベースからレコードを削除するときのベスト プラクティスは何ですか?
たとえば、このオンライン予約ツアー アプリケーションを持っているとします。
レコードを削除するツアー テーブルがありますが、ツアー テーブルは予約テーブルと顧客テーブルにもリンクしています。ここで、レコードの削除を許可するか、アーカイブなどを示すフラグのようなフィールドが必要です.
ベスト プラクティスとは
よろしく、ティー。
Branko が言ったように、それは要件 (およびデータベースのレイアウト) によって異なります。
完全な履歴を保持したい場合は、おそらくあまり削除しないでしょう。キャンセルフラグを設定するだけがおそらく最善でしょう。
データベース設計の例に関して言えば、ツアーは予約にリンクする必要がありますが、顧客にはリンクしないでください(予約は、ツアーから顧客への多対多のマッピングを提供する必要があります)。
あなたの例に基づいて構築するには、おそらく、どのツアーでも予約されている顧客を削除することは許可されるべきではありません (または予約も削除する必要があります)。ツアーが削除された場合、そのツアーのすべての予約を削除する必要があります (また、予約 (またはツアー) の削除時に、予約がキャンセルされたことを顧客に通知するためのトリガーが必要になる場合があります。または、このトリガーは外部で処理できます)。データベース)。
おそらく上記からわかるように、具体的なルールはありません。特定のデータベース設計で何が許され、何が許されるべきではないか、何かが削除されたときに何が起こる必要があるかを論理的に考える必要があります。
デフォルトは、最も安全な設定である外部キーの ON DELETE NO ACTION です。言うまでもなく、ON DELETE CASCADE やデフォルト以外の設定を、その設定の各インスタンスについて具体的に検討したり、その設定を使用することが正当化されるかどうかを検討したりせずに、全面的に自由に使用するべきではありません。
また、理想的には、誰かがデータベースを乗っ取った場合に間違ったものを誤って削除することが難しいようにデータベースを設計する必要があります。物事はどのような順序で行う必要があります)。外部キーをより厳密または安全に設定すると、これがより困難になります。