2

アプリのこの部分の開発をしばらく延期しているのは、これを循環的な方法で実行したいからですが、学校で講師が教えてくれたのを覚えているので、それは悪い考えだと感じています。

私が残したこの例に関係のないものはすべて無視して、注文システムの設計があります。

  • クレジットカード
  • お客様
  • 注文

そうして欲しい、

  • 顧客はクレジットカードを持つことができます (0-n)
  • 顧客からの注文 (1-n)
  • 注文には 1 人の顧客がいます (1-1)
  • 注文には 1 枚のクレジット カードがあります (1-1)
  • クレジット カードは 1 人の顧客を持つことができます (1-1) (一意の ID であるため、cc 番号の一意性を無視できます。夫/妻は cc インスタンスなどを共有できます)

基本的に、最後の部分は問題が発生する場所です。クレジット カードが拒否され、別のカードを使用したい場合があります。これは、「現在の」カードを更新する必要がありますが、これはその注文に使用されている現在のカードを変更するだけであり、変更することはできません。顧客がディスク上に持っている可能性のある他の注文。

これにより、3 つのテーブル間に円形のデザインが効果的に作成されます。

考えられる解決策: どちらか

円形のデザインを作成し、参照を与えます:

  • cc ref 注文、
  • お客様の cc への参照
  • 顧客参照注文

また

  • お客様の cc への参照
  • 顧客参照注文
  • 3 つすべてのテーブル ID を参照する新しいテーブルを作成し、注文に固有のものを配置して、常に 1 つの cc のみがその注文に対して最新であるようにします。

基本的に、どちらも同じデザインをモデル化していますが、解釈が異なります。現時点では後者のオプションが最も気に入っています。（それが理にかなっていれば）

私の質問は、

  • それぞれの長所と短所がある場合はどうなりますか?
  • 循環関係/依存関係の落とし穴は何ですか?
  • これはルールの有効な例外ですか?
  • 後者よりも前者を選ぶべき理由はありますか?

ありがとうございます。明確化/説明が必要なことがあればお知らせください。

--更新・編集--

記載した要件に誤りがあることに気付きました。SOの物事を単純化しようとすると、基本的にボールを落としました。別のレイヤーを追加する Payments 用の別のテーブルがあります。難点は、注文には複数の支払いがあり、異なるクレジット カードを使用できる可能性があることです。（他の支払い方法についても知りたい場合）。

根本的な問題は依然として同じであり、これは実際には別の複雑さのレイヤーを追加するだけだと思う​​ので、ここでこれを述べます.

4

5 に答える 5

7

顧客は 0 個以上のクレジット カードを関連付けることができますが、関連付けは動的であり、行ったり来たりする可能性があります。ご指摘のとおり、クレジット カードは複数の顧客に関連付けることができます。したがって、これは最終的に n:m テーブルになり、おそらく「アクティブ」のフラグ列があります。

注文は 0 または 1 枚のクレジット カードと静的な関係にあり、販売が完了した後は、cc と顧客の関係がどうなろうと、cc の値をいじることはできません。order テーブルは、販売時の cc に関するすべての関連情報を個別に保存する必要があります。販売を他のテーブルの他のクレジット カード列と関連付ける理由はありません (変更される可能性がありますが、販売には影響しません)。

于 2009-04-27T00:16:53.193 に答える
1

うーん？

顧客は複数のクレジット カードを持っていますが、現在のカードしか持っていません。オーダーには 1 つのカードが割り当てられます。顧客が何かを購入すると、デフォルトのカードが最初に試されます。それ以外の場合は、メインのカードを変更できますか?

ここには循環参照はありません。ユーザーのクレジット カードが変更されても、注文は同じままです。テーブルは次のようになります。

  • 顧客: id、現在のカード
  • クレジット カード: id、number、customer_id
  • オーダー: id、Card_id、Customer_id

編集：おっと、フィールドを忘れました、ありがとう。

于 2009-04-27T00:17:42.693 に答える
1

問題はオーダーのモデリングにあると思います。1 つの Order に 1 つのクレジット カードが含まれるのではなく、1 つの注文に複数のクレジット カードを関連付けることができるようにする必要があります。基本的に、注文とクレジットは多対多です。これを DB でモデル化するには、関連付けテーブルを導入する必要があります。たとえば、PaymentHistory です。注文に新しいクレジット カードが必要な場合、新しいクレジット カードを作成し、それを注文に関連付けて、関連付けられている PaymentHistory をアクティブとしてマークするだけです。

于 2009-04-27T00:24:30.913 に答える
0

これは 1 年前のものですが、注目すべき点がいくつかあります。

注: オンラインの NON-ACCOUNT プロセスの場合: 顧客は購入者としてより適切に定義され、おそらく別のタイプの顧客 (受益者/受取人) も存在します。他の人のために航空券や花などを購入/購入することができます。この 2 つの役割は、異なるビジネス プロセス (支払いと商品の送付) を伴うため、明確に分離する必要があります。

アカウント以外のプロセスである場合は、クレジット カードの詳細を保持するべきではありません。これはセキュリティ リスクです。この情報を保持することで、購入者を危険にさらすことになります。クレジット カードはリアルタイムで処理されるため、情報は破棄する必要があります。

アカウントのお客様: 唯一の例外は、誰かがアカウントを開設し、その後の購入で使用するためにクレジット カード情報を提供した場合です。このような場合、クレジット カード情報への変更は、アカウント管理プロセスの一環として、トランザクションの外で行われます。

重要な点は、モデリングとコーディングを開始する前に、ビジネス プロセスを完全に理解していることを確認することです。

于 2010-05-29T00:46:30.547 に答える
0

データに循環関係がある理由が何であれ、それらの 1 つを宣言するのを「忘れて」、テーブルが一括読み込み順序を持つようにすると、非常に満足できます。

これは、予期しないときに役立ちます。

于 2009-04-27T00:24:40.057 に答える