- PR -

サロゲートキー利用時のチェックボックスについて

1
投稿者投稿内容
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-05-29 16:33
いつもお世話になっております。

サロゲートキーを利用して、テーブル設計について
質問させていただきたいことがあります。
UIとテーブル設計は実際に切り離しを行い考えて
テーブルの設計を行っていたのですが、
実際に仕様書を作成していく中で、Ｗｅｂページをはじめ
さまざまな箇所にあるチェックボックスに対しての処理は
どのように行ったらよいか、分らなくなりました。

例えば、下記のような構造でテーブルとデータがあったとします。

■テーブル
ID int,　// ←　自動栽番
user_id int,
chdata int

新規登録の場合は、自動栽番によって、IDが付与し、
チェックボックスのvalueが、chdataに格納されるとします。
更新の場合は、どのような処理にしたほうがよいのでしょうか？

ナチュラルキーの場合は、Delete & Insartを行い、
Updateなどの意識はしておりませんでした。
しかし、Delete & Insartをすると、自動栽番で付与される
番号が、肥大するような気がします。

サロゲートを利用している方は、どのように
コーディング及び設計をされているのでしょうか？

お手数をおかけしますが、ご教授お願いいたします。
KOX
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 142
投稿日時: 2007-05-29 18:21
質問の意図がよくわからないですが、
サロゲートキー云々の話ではないような・・・

サロゲートキーを使おうが使わなかろうが、
キーにあわせてUpdateでしょう。
Delete&insertはコストがかかるから、あまり使用しません。

#チェックボックスのくだりがよくわからない。
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-05-30 21:39
ご回答ありがとうございます。
少し混乱してしまい質問をしてしまいました。
サロゲートキー云々ではないですね。

チェックボックスの件ですが、
下記のようなＨＴＭＬがあったとします。
<input type="checkbox" name="hoge[]" value="A">りんご
<input type="checkbox" name="hoge[]" value="B">みかん
<input type="checkbox" name="hoge[]" value="C">なし
<input type="hidden" name="userId" value="taro">

この、チェックボックスをテーブルに、

ID |user_id |chdata
------------------------------------
1 |taro |A
2 |taro |B
3 |taro |C

このような形で格納したいと考えております。
登録系のような画面では、insertのみを使用します。
しかし、編集系の画面では、チェックボックスが外れた際に、
対象となるデータをdeleteしようと考えております。
編集系の処理をしようとした場合、Selectで対象となる
データがあるか検索を行い、無ければInsartするといった
処理にするのがよいか、Deleteしておいてその後にInsartするのほうが
よいかどちらの手段が多く利用されているのでしょうか？

サロゲートキーは、
Delete & Insart に比べ、
Select & Insart or Delete にしたほうが無駄なカウントが防げそうですが、
このようなテーブル構造上の場合、サロゲートは不必要な気がしてきました。
KOX
大ベテラン
会議室デビュー日: 2004/08/23
投稿数: 142
投稿日時: 2007-05-31 11:55
引用:

YMMさんの書き込み (2007-05-30 21:39) より:
このような形で格納したいと考えております。
登録系のような画面では、insertのみを使用します。
しかし、編集系の画面では、チェックボックスが外れた際に、
対象となるデータをdeleteしようと考えております。
編集系の処理をしようとした場合、Selectで対象となる
データがあるか検索を行い、無ければInsartするといった
処理にするのがよいか、Deleteしておいてその後にInsartするのほうが
よいかどちらの手段が多く利用されているのでしょうか？

Updateは関係なかったんですね・・・

このようなケースの場合は、IDもHTMLに埋め込みます。

--排他処理が必要ないと仮定した場合
IDがあってチェックがはずれていれば、Delete。
IDがなくチェックされていればInsert。
未記入
会議室デビュー日: 2007/05/23
投稿数: 2
投稿日時: 2007-05-31 14:10
引用:

KOXさんの書き込み (2007-05-31 11:55) より:
このようなケースの場合は、IDもHTMLに埋め込みます。

--排他処理が必要ないと仮定した場合
IDがあってチェックがはずれていれば、Delete。
IDがなくチェックされていればInsert。


仕様にもよりますが、そのテーブルをサロゲートにする意味ってあります？
そのテーブル自体がファクトテーブルである場合は、サロゲートの利用は
考えたほうがいいですよ。

サロゲートのメリットは多くあります。
ざっくり見ると業務都合のコード変更であったり、
ORMでの利用を考えれば、サロゲートは便利かもしれませんが、
YMM さんが提示したサンプルでは、別に｢果物マスター｣みたいな
テーブルがあると思うんです。
そのマスターと、ユーザーテーブルにサロゲートキーを作成し、
実際にチェックボックスのデータを格納するテーブルは、
サロゲートを利用せずuser_idとchdataだけにしたほうが
よいのではないでしょうか。
uesr_idはユーザーテーブルのサロゲート、chdataは
果物マスターのサロゲートキーが入ります。

サロゲートをキーを無くし、私としては、
件数にもよりますが、Delete & Insartでもよい気がします。

全てのテーブルにサロゲートキーを作成する人がいますが、
意味ないだろ〜と、いう箇所もありますので、
正規化をした後に、サロゲートキーを導入する箇所と
しない箇所を検討したほうがよいと思っております。

なぜ全てのテーブルにサロゲートキーを入れたがるのでしょうか？

この板を読んでいる皆さんはどう思いますか？

はぶさんの｢楽々ERDレッスン｣は、非常にいい本ですね。
でも、サロゲートキーを利用することにより、ORMの利用が
簡単になったとしても、それ以外の箇所でコーディング量が
多くなってしまうのであれば、私は嫌ですね。
Web + DB vol.38の｢第5章コードをなくす技術 O/Rマッパ編｣も
全てのテーブルに、サロゲートキーをいれても、
設計の内容次第では、コードは増えるだろうと、単純に思いました。

[ メッセージ編集済み 編集者: 未記入 編集日時 2007-05-31 14:15 ]

[ メッセージ編集済み 編集者: 未記入 編集日時 2007-05-31 14:22 ]
1

スキルアップ／キャリアアップ（JOB@IT）