- ベストアンサー
マスタの更新について
- マスタを登録・更新するプログラムを作成しています。入力画面には商品コード、商品名、備考の項目を配置しています。
- マスタの内容を選択してデータを作成しているため、マスタを更新する際は商品コードの変更はできません。
- オートナンバー型のフィールドを使用するかどうかは一般的です。適切な対応方法についてアドバイスをいただけませんか?
- みんなの回答 (6)
- 専門家の回答
質問者が選んだベストアンサー
商品コードとは別に、オートナンバー型のフィールドを作成しておいた方が安心だと思います。 主キーが商品コードの場合、一意制約の関係で不便が生じると思います。 例えば以下の手順です。 (1)商品コードAで登録 (2)商品コードAのマスタの削除フラグを立てる (3)新しく商品コードAを登録(出来ず。同じ商品コードの物は再登録出来ない) もちろん削除フラグを立てたマスタをDELETEすれば問題ありませんが、あまりおすすめしません。
その他の回答 (5)
- y_mochiduki
- ベストアンサー率75% (15/20)
> 商品マスタのテーブルから主キーを無くしてプログラム上で商品コードが重複しているかを確認する方法はどうなのでしょうか。 その場合、複数のスレッドで重複確認->登録の処理がされることを考える必要があります。 AとBの二つのスレッドが同時に未登録の001という商品コードの重複確認した場合、どちらも登録可能と判断されてしまいます。これを回避するためにはトランザクション処理をするなどの同時に重複確認->登録の処理が行われないようにする必要があります。この手間を考えると、DB側で勝手に重複しないように連番を割り振ってくれた方が楽で安全だと思います。 同じような機能を自分で新規に作成するよりは、多くの人が既に使用しているDB側の機能を使用した方が良いと思います。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
- 山田 太郎(@f_a_007)
- ベストアンサー率20% (955/4574)
>商品マスタのテーブルから主キーを無くして >プログラムで商品コードが重複しているか否かを確認。 商品コードが重複しているか否かを確認するのは、商品を登録するアプリケーションにとっての不可避の機能です。そして、その際に、同一商品名で仕入れ単価等の属性が異なる商品をどういう形で処理するのかを決めるのも同アプリケーションの役目。そういうアプリケーションの設計とテーブル設計は対になります。しかし、それとリレーショナル・データベース設計の基本を崩すのとは訳が違います。それに、カード型データベースなんてのは、この21世紀には存在しないでしょう。 >結果的には登録できる商品コードは一意になります。 >このような方法はどうなのでしょうか。 主キーを推奨する理由1、2、3を否定するだけの説得力はありません。 と、思います。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
- maiko0318
- ベストアンサー率21% (1483/6969)
>商品マスタのテーブルから主キーを無くしてプログラム上で商品コードが重複しているかを確認する方法 もちろんOKです。 商品コードの重複を許さない設計で、 その機能をデータベースに持たせるかプログラムで持たせるかの違いです。 課題) もし、商品コードの重複が発見されたら、 1)その機能をデータベースに持たせている場合は データベースの会社に問い合わせなければならなくなる。 回答までひたすら待つことになる。 2)その機能をプログラムに持たせている場合は 自分たちで該当プログラムのチェックをすればいいことになる。 修正のめども立ちやすい。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
- maiko0318
- ベストアンサー率21% (1483/6969)
オートナンバー型のようなフィールドは不要と考えます。 商品コードは商品に対して一意であって、削除する(削除フラグを立てる)事はあっても 更新することはありません。 商品コードA、商品名ホウキに削除フラグを立てて 商品コードA、商品名ちりとりに変更されたら Aというコードはホウキなのかちりとりなのかわからなくなるからです。 現在、スーパーなどで売られているものにはバーコードが付いていますが、 あれは世界で一意に番号が付いています。世界のどこに行っても同じものはないのです。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
補足
回答ありがとうございます。 再度、質問をしてもいいでしょうか。 テーブルの話からずれるかも知れませんがすみません。 商品マスタのテーブルから主キーを無くしてプログラム上で商品コードが重複しているかを確認する方法はどうなのでしょうか。 結果的には登録できる商品コードは一意になります。 このような方法はどうなのでしょうか。 すみませんが再度、アドバイスいただけたら幸いです。 皆さん、宜しくお願いします。
- 山田 太郎(@f_a_007)
- ベストアンサー率20% (955/4574)
【商品マスター/商品台帳】 [id]・・・・・・1,2,…,N [商品名]・・・・D712_V7GG ・・・・・ Q、オートナンバー型の列を作成するものなのでしょうか? A、推奨は、採番方式によるシリアル番号の付与。 理由1、リレーションシップ機能を利用する基本だから。 理由2、商品の登録順を記録する意味もあるため。 理由3、[商品名]の重複による不具合を回避できるから。 理由4、[商品名]の訂正・変更を可能にするため。 理由4は理由1を別の側面から述べたに過ぎません。ですから、主な理由は3つかと思います。 理由2は、非常に現実的なそれかと思います。列[id]を用意しなかった場合、【商品マスター/商品台帳】を登録順に参照することはおよそ不能。これは、致命的とも言える欠陥です。 理由1は、いわずもがなですので説明は割愛します。 理由3は、テーブル設計者としては想定しておくべきです。 なお、私は、いわゆる[id]列など主キーにオートナンバー型を採用したことは一度もありません。テーブルメンテナンスを想定した場合、採番方式によるシリアル番号の付与がお勧めです。 採番方式1:採番テーブルを利用する。 採番方式2:採番テーブルでなく関数を利用する。 昔と比較するとPCの性能は格段に向上しています。ですから、テーブルから現最大値を求めて+1する関数を利用しても何ら問題ないと思います。 まあ、単なる昔パソコンを齧った程度の素人の回答。適当に参考にされてください。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
補足
回答ありがとうございます。 再度、質問をしてもいいでしょうか。 テーブルの話からずれるかも知れませんがすみません。 商品マスタのテーブルから主キーを無くしてプログラム上で商品コードが重複しているかを確認する方法はどうなのでしょうか。 結果的には登録できる商品コードは一意になります。 このような方法はどうなのでしょうか。 すみませんが再度、アドバイスいただけたら幸いです。 皆さん、宜しくお願いします。
お礼
回答、ありがとうございます。 返答が遅くなってすみません。 既に8割がた作成が進んでしまっているのでプログラムで対応する事にしました。 次の開発に皆さんの意見、またアドバイスを生かしたいと思います。 どうもありがとうございました。
補足
回答ありがとうございます。 再度、質問をしてもいいでしょうか。 テーブルの話からずれるかも知れませんがすみません。 商品マスタのテーブルから主キーを無くしてプログラム上で商品コードが重複しているかを確認する方法はどうなのでしょうか。 結果的には登録できる商品コードは一意になります。 このような方法はどうなのでしょうか。 すみませんが再度、アドバイスいただけたら幸いです。 皆さん、宜しくお願いします。