-1

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

注文、顧客、製品に関するベスト プラクティスは何ですか。クライアントは注文、顧客、および製品を削除できますか?

現在、次のような注文、顧客、製品間の関係の原則に基づいてデータベースを設計しています。

顧客
ID
名
...

品番 名 価格 ...
_


注文
ID
CustomerID
OrderDate
...

注文 明細
ID 注文 ID 製品ID

このように、すべての異なるテーブルを接続できます。しかし、クライアントが製品を削除した場合、数か月前に作成したそのアイテムが含まれていた注文を後で開いたときにどうなるでしょうか。削除されたので、なくなってしまいます。顧客についても同様です。

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

クライアントが製品を削除することを決定するたびに製品を無効にするとしたら、無効にした製品と同じ製品 ID を持つ新しい製品を後で追加しようとするとどうなりますか?

あなたの知恵を共有してください:D

4

3 に答える 3

1

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

同じ商品IDで新しい商品を無効にしてから入力する場合、なぜそうするのかわかりません。各商品IDは理由により一意であり、商品を中止しても、その商品IDを保持する必要があります。だからあなたは記録を持っています。ただし、必要に応じて、ビジネスルールに「この製品IDでアクティブな製品がない場合は許可します。アクティブな製品があり、同じ製品IDの場合、エラーをスローします。」したがって、その商品IDを持つアクティブな商品を1つだけ許可しますが、正直なところ、これは混乱を招くと思います。バックエンドでは、各商品がテーブル間をリンクするために変更されない一意のIDを使用する必要があります。

于 2010-10-03T19:31:52.443 に答える
1

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

于 2010-10-03T19:35:02.937 に答える
1

「クライアントが製品を削除することを決定するたびに製品を無効にするとしたら、無効にした製品と同じ製品 ID を持つ新しい製品を後で追加しようとするとどうなりますか?」

お客様のビジネス シナリオに完全に依存します。お客様が現在維持している方法で独自のものは何ですか? （手作業で？） 生産中止になった旧製品が急遽再登場した場合の対応は？(彼らはそれを新しい製品として扱いますか、それとも古い製品を参照し始めますか?) これらの質問に対する正しい答えも間違った答えもないと思います。それは機能に依存します。 ) すでに顧客がフォローしており、それらをソフトウェア機能にマッピングします。

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

于 2010-10-03T19:41:11.707 に答える