小さなCRM/請求システムのデータベース設計

Question

私は現在、クライアントのための小さな顧客関係と請求書管理システムを開発しています。そして、私は議論したいいくつかの小さな問題に遭遇しました。

注文、顧客、製品に関するベストプラクティスは何ですか。クライアントは注文、顧客、製品を削除できる必要がありますか？

現在、私は注文、顧客、製品の間の関係の原則に関するデータベースを設計しています。

お客様
ID
名前
...

製品
ID
名前
価格
...

注文
ID
顧客ID
注文日
...

オーダーライン
ID
OrderId
製品番号

このように、私はすべての異なるテーブルを接続できます。しかし、私のクライアントが製品を削除した場合、彼が後でそのアイテムが入った数ヶ月前に作成した注文を後で開いたときに何が起こるか。削除されているので、それはなくなります。顧客にも同じことが言えます。

削除]ボタンがクリックされたときに、製品と顧客を無効にする必要がありますか、それともベストプラクティスは何ですか？

クライアントがそれを削除することを決定したときに製品をDiableとする場合、彼が後で無効な製品と同じ製品IDを持つ新製品を追加しようとするとどうなりますか？そのアイテムをもう一度有効にする必要がありますか？

あなたの知恵を共有してください：d

Answer 1

「クライアントがそれを削除することを決定したときに製品をDiableとさせた場合、彼が後で無効製品と同じ製品IDを持つ新製品を追加しようとするとどうなりますか？

完全にあなたのビジネスシナリオに依存します - 顧客が現在それを維持する方法でユニークなものは何ですか？ （手動で？）以前に中止された古い製品が突然再び現れたとき、彼らはどのように扱いますか？ （彼らはそれを新製品として扱うのですか、それとも古い製品について言及し始めますか？）これらの質問に正しい答えや間違った答えはないと思います、それは機能に依存します - 既存のプロセスを理解することを常にお勧めします（ソフトウェアを除いて）既に顧客が続いてから、それらをソフトウェア機能にマッピングします。

例えば。いつでも「このコードが既に存在する製品を使用している製品を追加できます。新しいコードを作成する代わりに使用しますか？」一種のメッセージ。また、テーブルで外部キーとして使用する製品ID、および顧客を表示するために使用する製品IDは、より違うものです - それらを混同したくない。

Answer 2

なぜ注文を削除できるようにしたいのですか？そのようなシステムは注文をロックして、あなたが良い歴史を持っていることを知っていると思います。顧客にも同じことが言えますが、なぜそれらを削除するのですか？おそらく、それらを「アーカイブ」し、フラグを設定する必要があるため、顧客リストなどに表示されない方法です。

同じ製品IDで新しいアイテムを無効にして入力することについては、なぜあなたがそれを行うのか、各製品IDは理由で一意です。だからあなたはレコードを持っています。しかし、必要に応じて、ビジネスルールに制約を付けることができます。同じ製品IDを使用して、エラーを投げます。」したがって、その製品IDを使用して1つのアクティブ製品のみを許可しますが、正直なところ、これは混乱していると思います。バックエンドでは、各製品がテーブル間でリンクするために変わらない一意のIDを使用する必要があります。

Answer 3

「削除」する代わりに、ISACTIVE用のブール列を追加します。そうすれば、履歴データを失うことはありません。たとえば、顧客を削除できる場合、その顧客に関する履歴を見ることができず、統計データを困難または不可能にすることができます。注文テーブルの場合、「現在」、「キャンセル」、「充填」などの列が同じことを成し遂げることができます。その列は、ルックアップ/コードテーブルのコードである必要があります。