モデルのスケッチをしましたが、関係(識別と非識別)が正しいかどうかわからないので、それを通過させ続けたくありません。
私がしたことを見て、それが正しいかどうかを教えていただければ幸いです。
モデルのスケッチをしましたが、関係(識別と非識別)が正しいかどうかわからないので、それを通過させ続けたくありません。
私がしたことを見て、それが正しいかどうかを教えていただければ幸いです。
1つの製品が多数の注文に含まれている可能性があります。1つの注文に多くの製品が含まれる場合があります。
相互参照テーブルには次の構造があります。
+-----------------+
| orders_products |
+-----------------+
| id PK |
| orders_id PK |
| products_id PK |
+-----------------+
id
注文に同じ商品を複数回含めることができない限り、自動インクリメントフィールドは必要ないと思います(これは意味がありません)。注文で指定された各製品の数量を記録するためにこれを行う場合は、代わりquantity
にそれぞれの列を作成することをお勧めします。order_id -> product_id
そのテーブルの構造を次のように変更します。
+-----------------+
| orders_products |
+-----------------+
| orders_id PK |
| products_id PK |
| quantity |
+-----------------+
1人のユーザーが多くのアドレスプリセットを持っている場合があります。1つのアドレスプリセットは1人のユーザーにのみ属することができます。
addresses
テーブルをテーブルに接続するのは良い考えではないと思いorders
ます。ユーザーが自分のアドレスプリセットの1つを削除または更新した場合はどうなりますか?削除/変更は、そのアドレスを含む過去の注文にカスケードされます。カスケードアクションの設定方法によっては、それらの注文レコードが完全に削除されるか、古い注文に関する誤った情報が含まれることになります。これは、参照整合性が適切でない1つの状況です。注文が行われると、その注文に指定された配送先住所を後で変更することはできなくなります。
代わりに、addresses
テーブルを使用して、ユーザーが持っているアドレスプリセットのリストを保存するだけです(ユーザーのドロップダウン選択を生成できるようにするため)。orders
ユーザーが注文を送信するときは、実際のテキストの住所情報をテーブルの「shipping_address」列に挿入するだけです。
識別関係と非識別関係の違いをよりよく理解するには、以下を参照してください。
そしてここでの私の答え: