する質問をすることでしか得られない、回答やアドバイスがある。93※ベストアンサー付けてしまいましたがこれは操作ミスで、まだ解決していないです。テーブル設計で悩んでいることがあります。非常に簡単な例ですが、上図のような商品マスタの設計で、productテーブルには自社の製品コードと他のテーブル間(例ではproduct_info、deliveryテーブル)で共有するフィールドがいくつか入っています。product_infoはその製品の詳細なスペック表のイメージです。問題なのはproduct_infoに入っている製品情報は自社だけでなく、他社の製品の情報も入っており、productとは別のコード体系で管理されていて、かならずしもproductテーブルと紐付いている訳ではないところです。仕様ではproduct_infoテーブルはcsv形式でデータ更新を行う予定で、product_infoを更新するときにproductテーブルに紐付いているフィールドはproductテーブルも更新します。このような設計でも運用出来なくは無いですが、今後の運用に不安を感じています。できれば同一のフィールドを複数テーブルで持ちたくないのですが、何か良い案はないでしょうか。例が分かりづらいかもしれないですが、よろしくお願いいたします。追記product_infoテーブルで持っている他社製品情報はこのテーブル以外では参照しませんattachmentクリップ1気になる質問をクリップするクリップした質問は、後からいつでもマイページで確認できます。クリップした質問に回答があった際、通知やメールを受け取ることができます。自分も答えを知りたい質問者以外のユーザにも役立つ評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。質問の評価を上げたことを取り消します低評価-評価を下げられる数の上限に達しました評価を下げることができません1日5回まで評価を下げられます1日に1ユーザに対して2回まで評価を下げられます質問の評価を下げるteratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。コメントをしてください。送信する質問の評価を下げる機能の利用条件この機能を利用するためには、以下の事項を行う必要があります。製品の詳細情報という扱いで合っているのでしょうか。どちらかに紐付く、と。それぞれに対して別々に用意した方がよいような気がします。間を紐付けるためのテーブルを別に設けてやる感じでしょうか。一つにまとめてしまう(自社でも他社でも「製品」だからエンティティーとしては一つ)か、ですかねえ。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。17:47コメントありがとうございます。deliberyは納品先テーブルです。上図ではproductテーブルに紐付いているテーブルが複数あるという例で出しています。他社製品情報はproduct_infoのみで扱っています。コメントありがとうございます。deliberyは納品先テーブルです。上図ではproductテーブルに紐付いているテーブルが複数あるという例で出しています。他社製品情報はproduct_infoのみで扱っています。18:52難しいですね難しいですねキャンセル完了するlink+3製品のコード体系が違うものを管理しようとするなら、製品コードのみだけでは管理できないですから、識別できる情報が必要です。「会社コード+製品コード」などで一意にするしかありません。上記はナチュラルキーですので、リレーションに影響を与えないように、サロゲートキーで管理するのが良いかと思います。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。commentコメント投稿link+2不安しか無いですね全部DBでやらなければならないんですか?csvがプログラムから吐かれているものなら良いんですが、手作業が含まれていると高頻度でミスタイプでロールバックしなければならなくなると思います。import失敗ならまだ良いですが、桁間違えみたいな正フォーマット誤データですと裏でゴリゴリ破壊が進みますよ。他社コードが自社コードと衝突したら目も当てられません。データ更新プログラムを作るのをおすすめします。その上で他社データを自社コード体型に吸収しproduct_infoに会社コードカラムと他社コードカラムをつけ自社なら空、他社なら他社(1社ならbool)コードと他社製品コードを入れるという案を考えます。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。編集コメントありがとうございます。csvに関してはプログラムでもやる予定です。似たような設計は私も考えたのですが、product_infoテーブルに入っている他社製品レコードはproduct_infoテーブルだけで管理しているデータで他のテーブルからは参照されません(本来考えにくいことですが)。そのようなレコードはproduct_infoテーブル内だけでとどめておきたいという気持ちがあります。情報の後出しで申し訳ないですコメントありがとうございます。csvに関してはプログラムでもやる予定です。product_infoテーブルに入っている他社製品レコードはproduct_infoテーブルだけで管理しているデータで他のテーブルからは参照されません(本来考えにくいことですが)。そのようなレコードはproduct_infoテーブル内だけでとどめておきたいという気持ちがあります。情報の後出しで申し訳ないですキャンセル完了するlink+2基底のテーブル(仮にproduct_base)で全ての製品に共通するカラムを定義します。自社の製品はproduct_baseのプライマリキーに紐づいたテーブル(product)に自社製品だけが持つカラムを定義します。product_infoもproduct_baseに紐づけます。他社の製品も同様です。評価が高い回答ほどページの上位に表示されます。remove低評価0回答の評価を下げる下記のような回答は推奨されていません。評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。17:55コメントありがとうございます。そのような設計がいいでしょうか。基底テーブル(product_base)に複数のテーブルを紐付けると所謂中間テーブルが紐付けたいテーブル分必要になると思いますが、私はこの中間テーブルによってテーブル数が増えるのも見通しが悪くなる気がして躊躇していました。コメントありがとうございます。そのような設計がいいでしょうか。基底テーブル(product_base)に複数のテーブルを紐付けると所謂中間テーブルが紐付けたいテーブル分必要になると思いますが、私はこの中間テーブルによってテーブル数が増えるのも見通しが悪くなる気がして躊躇していました。17:58RDBにおいて中間テーブルが必要なのは多対多結合のときぐらいです。1対0-1の時などには不要です。RDBにおいて中間テーブルが必要なのは多対多結合のときぐらいです。1対0-1の時などには不要です。18:23hihijijiさんの設計ではproduct_baseで発行されるプライマリキーをproductテーブル、product_infoテーブルそれぞれに持たせる設計ということでしょうか。product_infoテーブルでproduct_baseのキーを持たせるフィールド(仮にproduct_base_key)を設ける場合、product_infoテーブルはproductテーブルと紐付くレコードもあるので、product_base_keyフィールドにはproduct_baseのidが必ずしも入るわけではなく参照整合性制約がかけられないと思われます。私の勘違いであれば申し訳ありません。hihijijiさんの設計ではproduct_baseで発行されるプライマリキーをproductテーブル、product_infoテーブルそれぞれに持たせる設計ということでしょうか。product_infoテーブルでproduct_baseのキーを持たせるフィールド(仮にproduct_base_key)を設ける場合、product_infoテーブルはproductテーブルと紐付くレコードもあるので、product_base_keyフィールドにはproduct_baseのidが必ずしも入るわけではなく参照整合性制約がかけられないと思われます。私の勘違いであれば申し訳ありません。18:34product_infoテーブルはproduct_baseを介してproducと紐づきます。この場合のproduct_baseは中間テーブルではなく親と思って下さい。product_infoテーブルはproduct_baseを介してproducと紐づきます。この場合のproduct_baseは中間テーブルではなく親と思って下さい。編集すいませんちょっとイメージがわきません。自分がproductを一番の親だという考えが強いからかもしれません。別の人をベストアンサーにしてますがこれは操作ミスです。すいませんちょっとイメージがわきません。自分がproductを一番の親だという考えが強いからかもしれません。別の人をベストアンサーにしてますがこれは操作ミスです。19:01よく使われる「クラステーブル継承」パターンです。欠点としては自社製品でありかつ他社製品でもある製品が作れてしまう点があげられます。これはカラムが明らかに違うので実運用上問題となることが殆ど無いでしょう。詳しくは「クラステーブル継承」でググってください。使われる「クラステーブル継承」パターンです。欠点としては自社製品でありかつ他社製品でもある製品が作れてしまう点があげられます。これはカラムが明らかに違うので実運用上問題となることが殆ど無いでしょう。詳しくは「クラステーブル継承」でググってください。0赤い文字のエラーは消えましたがatomの文字の色が.phpだけつきません。頂いたご意見への回答は行っておりません。