Q&A
なぜ、いい案とは思えないのか追加すると回答が得やすいかと思います
jan テーブル
|id(int)|item_id(int)|client_id(int)|jan(varchar)|price(int)|rate(int)|
|:--:|:--:|:--:|:--:|:--:|
|1|1|1|1234567890|100|60|
item_idからjanやprice, rateを取得するような形になっていましたが、
新たに品番（product_number）からも取得できるようにする必要が出てきました。
そこで以下のようにテーブルを変更してitem_idで取得する場合とproduct_numberで取得する場合を切り分け用としているのですが、とてもいい案とは思えません。
もし良い方法があれば教えていただけると助かります。よろしくお願いします。
検討している変更
|id(int)|item_id(int)|client_id(int)|jan(varchar)|price(int)|rate(int)|product_number(varchar)|
|:--:|:--:|:--:|:--:|:--:|:--:|
|1|0もしくはnull|1|1234567890|100|60|ABC-0001|
経緯
itemテーブルとproductテーブルが存在していて、itemテーブルは商品のカテゴリーのような役割になっています。
もともとproductの種類数が多い為、janコードをすべてitem（カテゴリー）毎に統一しているという珍しい管理方法をしています。なのでproduct毎にjanを設定していませんでした。
そして今回必要な場合はproduct毎にもjanを設定しなければならなくなったという状況です。
itemテーブル
| id(int) | name(varchar) |
|---|---|
| 1 | アイテム1 |
productテーブル
|id(int)|name(varchar)|item_id(int)|product_number(varchar)|
|:--:|:--:|
|1|商品１|1|ABC-001|
追記
clientテーブル
取引先ごとにJANが違う場合があるのでJANテーブルが必要でした。
| id(int) | name(varchar) |
|---|---|
| 1 | 取引先１ |
id、item_id、product_numberがそれぞれ何を意味していて、それらの関係性はどうなっているのかを示さないと、勘で答えることになっちゃうんじゃないですかね。
そもそもなのですが、
> item_idで取得する場合とproduct_numberで取得する場合を切り分け
これを行う理由がわからないです。要件(なぜそれをしなければならないか等)から書いてある方がやりやすいかもしれません。
mikkameさん
こんなやっつけな感じで大丈夫なんだろうかと思って質問させていただきました。すみません。
moredeepさん
ありがとうございます、経緯などを追記させていただきました。
回答2件
0
ベストアンサー
別なコード体系を一つのテーブルに併用する事はよくあります。
極端に言えば、サロゲートキーとナチュラルキーなどが該当します。
さらに、ここに別な体系のナチュラルキーを追加しても別におかしくはありません。
他のテーブルのリレーションとして、混在させるのは不備となる場合はあるでしょうが、単独のテーブルだけでおかしいとは断言できません。
追記
現状の関係としては
・jan→（外部キー)→product
・jan→（外部キー)→item
・product→（外部キー)→item
ですね。
ネックになるのは、janが決まらないproductがあるかどうかです。
あり得るのなら、現状のまましかありませんが、無いという事なら
・product→（外部キー)→item
という関係は無く、productにitemは不要です
ただ、元々itemにjanが紐ついている状態では、itemはカテゴリーという位置付けでは無かったのではないですか？
純粋なカテゴリーという位置付けなら、
・product→（外部キー)→item
という関係で、productにjanの項目を持たせて、janは廃止というのが素直じゃないでしょうか。
これであれば、サロゲートキーでproduct_numberもjanもナチュラルキーとして各々確定するタイミングも独立させる事ができます
投稿2019/09/13 04:43
編集2019/09/13 06:13
総合スコア25327
ありがとうございます。
他のテーブルのリレーションとして混在しているかもしれません。関係ありそうなテーブルと経緯を追記しました。よろしくお願いします。
ありがとうございます。
もともと商品の種類数が多い為、janコードをすべてitem（カテゴリー）毎に統一しているという珍しい管理方法でしてjanが決まらないproductがほとんどなんです。
ただ今回必要な場合はproduct毎にもjanを設定しなければならなくなったという状況です。
では、janテーブルを廃止してproductに統合ですね
ただ、productに対してjan付きのitemを紐づけるような場合には決めが必要でしょうけど
ありがとうございます。
取引先でJANが違う場合に対応するために実はjanテーブルにはclient_idがありまして、関係ないのでややこしくなると思い、最初に省いてしまっていました。
まさかここで必要になるとは思いませんでした。なんども手間をかけてしまって…本当に申し訳ないです。
項目名だけでは関係が分からないので、ナチュラルキーでの一意キーを示してください。
ありがとうございます！
ナチュラルキーで一意なものはありません。
ユニークなのはそれぞれのテーブルにオートインクリメントで設定されたサロゲートキーだけです。
> ナチュラルキーで一意なものはありません
それは設計としてよろしくないですね。
例えばjanテーブルだと、(client_id, jan)が一意でなく重複して登録されるという事ですか？
ありがとうございます。
クライアント毎にjanを登録できるようにしているのですが、同じjanの場合もあるので、client_idとjanは重複する場合があります。
では、(item_id, client_id, jan)で一意ですか？
(item_id, client_id, jan)で一意になっております！
そういった具合で一意キーを明らかにして下さい。
以下のようになっております。
janテーブル
(item_id, client_id, jan)
itemテーブル
(name)
clientテーブル
(name)
productテーブル
(name)
productテーブルのproduct_numberは同じproduct_numberで色違いの商品が登録される可能性があるため一意ではありません。
product とjanの関係が(item_id, client_id, jan):(product_id)で1:1ならjanへの追加はproduct_numberではなくproduct_idでしょう。
product :jan=n:nなら中間テーブルが必要です。
ありがとうございます。
productテーブルが以下のようになっていてproduct_number毎にjanを設定したいのですが、そもそもproductの設計が変でしょうか？
1 商品１黄 ABC-001
2 商品１赤 ABC-001
3 商品１緑 ABC-001
色違いはproductとは別にした方が良いかと思います。
配列が可能なDBMSなら配列にする場合もありますけど、MｙSQLなら中間テーブルの扱いが良いかと。
Janを軸にする視点から抜け出せていないように見受けられます。
製品というオブジェクトを軸にし、それに対する属性として様々なものを付与していく（JANコードとか製品番号とか）と考えると明確になると思います。
最後まで本当にありがとうございました。
productの色違いを中間テーブルにしなかったところから、janテーブルにproduct_numberを追加せざるを得ないという違和感が生まれていたことがわかりました。
0
item_idとproduct_numberの相関関係による
- item_idおよびproduct_numberの両方がすべてのitemにユニークに付加されている場合
→正規化のしようもないので、それぞれ別にカラムを持てばいい
→ただしテーブルに二重にユニーク制限をかけるのでどちらか一つにして運用でカバーするのもありかも
- item_idもしくはproduct_numberのいずれか片方がユニークで全てに付加され、もう片方はユニークではないか抜けがある場合
→ユニークな方を軸に正規化すればよい
- item_idおよびproduct_numberの両方とも、ユニークでもなければ全てに付加されるわけでもない
→idを元に両方ともバラバラに正規化する
投稿2019/09/13 04:44
総合スコア116690
あなたの回答
tips
プレビュー
