Q&A
コメントありがとうございます。
deliberyは納品先テーブルです。上図ではproductテーブルに紐付いているテーブルが複数あるという例で出しています。他社製品情報はproduct_infoのみで扱っています。
※ベストアンサー付けてしまいましたがこれは操作ミスで、まだ解決していないです。
お世話になります。
テーブル設計で悩んでいることがあります。
非常に簡単な例ですが、上図のような商品マスタの設計で、
productテーブルには自社の製品コードと他のテーブル間(例ではproduct_info、deliveryテーブル)で共有するフィールドがいくつか入っています。product_infoはその製品の詳細なスペック表のイメージです。
問題なのはproduct_infoに入っている製品情報は自社だけでなく、他社の製品の情報も入っており、productとは別のコード体系で管理されていて、かならずしもproductテーブルと紐付いている訳ではないところです。
仕様ではproduct_infoテーブルはcsv形式でデータ更新を行う予定で、
product_infoを更新するときにproductテーブルに紐付いているフィールドはproductテーブルも更新します。
このような設計でも運用出来なくは無いですが、今後の運用に不安を感じています。
できれば同一のフィールドを複数テーブルで持ちたくないのですが、何か良い案はないでしょうか。
少し例が分かりづらいかもしれないですが、よろしくお願いいたします。
追記
product_infoテーブルで持っている他社製品情報はこのテーブル以外では参照しません
回答4件
0
製品のコード体系が違うものを管理しようとするなら、製品コードのみだけでは管理できないですから、識別できる情報が必要です。
「会社コード＋製品コード」などで一意にするしかありません。
但し、上記はナチュラルキーですので、リレーションに影響を与えないように、サロゲートキーで管理するのが良いかと思います。
投稿2018/08/09 11:28
総合スコア25188
0
ベストアンサー
product は自社製品の情報
delivery は他社製品の情報
product_info は製品の詳細情報
という扱いで合っているのでしょうか。
この結果として、product_info のレコードは、product か delivery のどちらかに紐付く、と。
本来なら product_info を product と delivery のそれぞれに対して別々に用意した方がよいような気がします。
ただそれが出来ないなら、product_info には別の ID を振るようにして、そのIDとproduct、delivery のID との間を紐付けるためのテーブルを別に設けてやる感じでしょうか。
あるいは逆に、product と delivery を一つにまとめてしまう（自社でも他社でも「製品」だからエンティティーとしては一つ）か、ですかねえ。
投稿2018/08/09 08:23
総合スコア13703
難しいですね
0
基底のテーブル(仮にproduct_base)で全ての製品に共通するカラムを定義します。
自社の製品はproduct_baseのプライマリキーに紐づいたテーブル(product)に自社製品だけが持つカラムを定義します。
product_infoもproduct_baseに紐づけます。
他社の製品も同様です。
投稿2018/08/09 08:48
総合スコア4150
コメントありがとうございます。
やはりそのような設計がいいでしょうか。
基底テーブル(product_base)に複数のテーブルを紐付けると所謂中間テーブルが紐付けたいテーブル分必要になると思いますが、私はこの中間テーブルによってテーブル数が増えるのも見通しが悪くなる気がして躊躇していました。
RDBにおいて中間テーブルが必要なのは多対多結合のときぐらいです。
1対0-1の時などには不要です。
hihijijiさんの設計ではproduct_baseで発行されるプライマリキーをproductテーブル、product_infoテーブルそれぞれに持たせる設計ということでしょうか。
例えばproduct_infoテーブルでproduct_baseのキーを持たせるフィールド（仮にproduct_base_key）を設ける場合、product_infoテーブルはproductテーブルと紐付くレコードもあるので、product_base_keyフィールドにはproduct_baseのidが必ずしも入るわけではなく参照整合性制約がかけられないと思われます。
私の勘違いであれば申し訳ありません。
product_infoテーブルはproduct_baseを介してproducと紐づきます。
この場合のproduct_baseは中間テーブルではなく親と思って下さい。
すいませんちょっとイメージがわきません。自分がproductを一番の親だという考えが強いからかもしれません。
また別の人をベストアンサーにしてますがこれは操作ミスです。
よく使われる「クラステーブル継承」パターンです。
欠点としては自社製品でありかつ他社製品でもある製品が作れてしまう点があげられます。
しかしこれはカラムが明らかに違うので実運用上問題となることが殆ど無いでしょう。
詳しくは「クラステーブル継承」でググってください。
0
不安しか無いですね全部DBでやらなければならないんですか？
csvがプログラムから吐かれているものなら良いんですが、手作業が含まれていると高頻度でミスタイプでロールバックしなければならなくなると思います。
import失敗ならまだ良いですが、桁間違えみたいな正フォーマット誤データですと裏でゴリゴリ破壊が進みますよ。
さらに他社コードが自社コードと衝突したら目も当てられません。
なのでデータ更新プログラムを作るのをおすすめします。
その上で他社データを自社コード体型に吸収しproduct_infoに会社コードカラムと他社コードカラムをつけ自社なら空、他社なら他社（1社ならbool）コードと他社製品コードを入れるという案を考えます。
投稿2018/08/09 08:25
総合スコア705
コメントありがとうございます。
csvに関してはプログラムでもやる予定です。
似たような設計は私も考えたのですが、
product_infoテーブルに入っている他社製品レコードはproduct_infoテーブルだけで管理しているデータで他のテーブルからは参照されません(本来考えにくいことですが)。なのでそのようなレコードはproduct_infoテーブル内だけでとどめておきたいという気持ちがあります。
情報の後出しで申し訳ないです
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。