eコマースの使用例：製品の削除
作成しているWebサービスのeコマース要素のデータベーススキーマの設計を開始しています。
私が頭を動かそうとしているのは、売り手（私のWebサービスのユーザー）が製品を削除するユースケースにどう対処するかです。
私が持っている問題は、この製品が顧客のバスケットで参照され、支払われた注文、保留中の注文、配送、過去の注文などになる可能性があるということです...
この問題は確かに、そのようなシステムを開発している誰もが遭遇した問題です。それに対処するためのベストプラクティスの方法があるかどうか疑問に思っていますか？
データベーススキーマレベルで対処できますか？または、製品の削除を許可する前に、データベースデータの特定の検証チェックが必要な場合や、顧客が製品への参照を含む注文に対して支払いをしようとしたが、その参照が削除された場合（つまり、製品は削除されました）。
ステータスフィールドで処理します。製品は、アクティブ、非アクティブ、入荷待ち、advance_sale、置き換え、または廃止することができます。アクティブなadvance_saleおよび入荷待ちの製品のみがユーザーに表示されます。
トランザクション中に状態が変化した場合の対処方法は、ビジネス要件です。一部の販売者は、顧客に通知し、商品をカートから削除してほしい場合があります。カートに商品を入れた顧客がチェックアウトできるようにすることもできますが、その商品は新しい注文に表示されません。カートアクティビティ（アイテムの追加/削除、数量の変更、チェックアウトの開始）が発生するたびに、顧客のカート内の商品をチェックする店舗ごとの商品適格性検証ツールがあります。ウィッシュリストや定期的な注文をサポートしている場合は、ソリューションでそれらも考慮に入れてください。
削除しないでください。マイクがコメントで指摘したように、廃止または利用不可としてマークします。製品が製造中止になった場合、販売ページには表示されなくなりますが、データベース参照はそのまま残ります。その製品の保留中の注文がある場合、ビジネス側（データベースではなく）はそれを処理する方法を理解する必要があります。それでも配送（在庫があると仮定）するか、それとも払い戻しを発行するだけですか？
とは言うものの、ifアイテムはショッピングカートや注文などで使用されていません。たとえば、誰かをトレーニングするために使用されているか、何らかの理由で誤って作成された場合などです。 。ただし、このシナリオでも、削除が安全であることを確認するために、多くの整合性チェックを行う必要があります。製造中止のマークを付けたほうがよいでしょう。
システムが製品を物理的に削除することは許可されません。単にアクティブフラグを「いいえ」に変更しました。これにより、アーカイブされた請求書を正しく作成できました。
2013年12月26日更新：ここにはもっと大きな問題があります
OPの質問をもう一度読んだ後、このWebサービスは複数の販売者によって使用されるようです。その場合、販売者と製品の間には多対多の関係があります。したがって、Productテーブルにアクティブブールフラグが含まれているだけでなく、ProductテーブルにはSellerIdを識別するForeingKeyが必要です。