ショッピングサイトのテーブル設計について

質問

練習でショッピングサイトを制作しています。

このサイトでは会員サービスもありますが、会員登録せずに商品を購入することもできます。

会員の場合、受注テーブルに会員コード(会員を一意に表す)があれば、それを元に会員テーブルから発送に必要な情報を取り出すことができます。

しかし非会員は会員テーブルに情報がないため、発送に必要な情報が別途必要になります。

非会員の情報はどこで管理するべきでしょうか？

回答No.2

BellBell

＞会員の場合、受注テーブルに会員コード(会員を一意に表す)があれば、それを元に会員テーブルから発送に必要な情報を取り出すことができます。

典型的なダメな設計の例ですね。

この分では、受注テーブルとやらに商品IDと数量でも持たせた上で、リンクでデータを引っ張ってきている設計になっているのではないでしょうか？
そうなっていたら、ダメダメダメの100乗ですね。

DBを設計する場合、リレーショナル(リンク、リンケージと呼称する場合もある)させなければならないデータと、リレーショナルさせてはいけないデータの区別が大切です。

設計ルール1：『お客様の目に触れる書類はリレーショナルさせてはいけない』です。

過去データを確認したい場合、過去データを再発行したい場合にどうするのでしょう？
たとえば、宅配伝票を汚してしまい再印刷の必要があるとしたら？

ユーザがその途中で住所を変更したとしたら、受注時とは別の住所へ発送するという事になってしまいます。

もし商品テーブルともリンクで繋いでいたら、商品金額を変更した場合、受注時の金額と違う金額をユーザーに請求するような事になってしまいます。

書類を出力(この場合は発送伝票や納品書)するという事は、再度まったく同じ書類を出力できるように、データをリレーションで引っ張ってくるのではなく、テーブルに固定データとして登録しなければならないという事です。
それが設計ルール1。

上記を踏まえると、受注テーブルに発送先の住所、郵便番号、宛名、電話番号が必要となるのは当然。
それなら、非会員ならどうデータを登録すればなどと悩む必要など存在しない。

また、どうせ登録内容を増やすなら自宅に送付のみだけではなく、贈答用に届け先を別途入力可能にすることも、発注者(贈り主)の入力も可能にするなども考えられる。

業務の流れは書類の流れなので、書類ベースでシステムを設計すれば必要なものが見えてきます。
宅配便の発送伝票を眺めるだけで、希望のお届け日、希望のお届け時間が必要だなどという事も判ります。
これは設計ルールというよりも、コツでしょうかね。

回答No.1

lupin-333333

＞テーブル設計について

これはテーブル設計の範疇ではない。システム設計とか、アプリ設計のレベル。

よく仕事でも、ミッションとかタスクとか、特別チームとか何とか班などと、定期の物と、不定期の物を区分けします。これをシステムに取り入れると、

コマンド、ジョブ、etc

なんて特定の処理をするルーチンなり、クラスなり、コマンドを作ります。

買い物をするジョブですね。そうするとコンピューター的には、１つのジョブに一つのIDをつけるわけですね。そのジョブをIDで管理するわけです。お客様には、このIDを、買い物ナンバーとかよんで、メールで送っているはずです。このナンバーと内部で管理するIDは同じでも違っていも言い訳です（設計による）。

と言うことは、そのジョブには、何が在るかといえば、

品物名前、数、値段、小計、合計、消費税、送料、重量、注文日、届け先、発想手段（運送やの名前など）、etc

がお客様から見えるデータですね。バックでは、

在庫状況、入手先、発注状況、入予定日、着荷日、発送日、原価、売価、etc

が同じジョブIDで管理されます。

これらは違うテーブルから呼び出されて、ジョブIDと言う仮想テーブル（実際にあっていもいいが）に全て埋め込まれます。

つまり、この仮想テーブルに、会員だろうが、スポットの客だろうが、住所、名前が、入るわけです。会員はただ、その仮想テーブルに入れる情報を最初からもっていることと、そのジョブIDのデーターを、顧客DBのなかで保持できることになります。

上記が、一つのシステム設計です。他にもいろんなやり方あるかと思います。