- - PR -
同じ主キーを持つデータの更新について
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2002-10-10 22:40
ashです。
http://ja.gotdotnet.com/quickstart/aspplus/ のSQL データベースのデータの更新 のサンプルを利用して 主キー フィールドも入力できるように、プログラムを作っていますが、 試しに、既にある主キー フィールドのレコードデータを入力すると 主キー フィールドのデータだけは変わらず、他のフィールドのデータが 更新されてしまいます。 別の方法として、入力した主キー フィールドのデータが 既にあるかどうか1件目から最後まで順番に調べていく方法が 浮かんだのですが、どのようにすれば可能でしょうか? ちなみに、上記のHPのサンプルコードの中に Dim NumCols As Integer = E.Item.Cells.Count 行のカウントを指しているみたいですが、その反対の縦の方が 分かれば、進めそうな感じなんですが、誰かどなたがご教授の程 よろしくお願い致します。 | ||||
|
投稿日時: 2002-10-11 08:30
こんにちは。
主キーというのは、そのテーブル内において、レコードを特定するためのモノです。これが変わると、リレーションシップが崩れます(回避策はあります)。そのため、普通は変更しません(変更してはいけません)。詳しくはデータベースについて勉強してください。 主キーは、たいていは数字にします。ORACLEであれば、たいていはシーケンスを作ってそれから取得します。私はシーケンスを使いたくないので、「Select MAX(ID)+1」で、現在使用されている最大値の次を取ります。AccessやSQL Serverであれば自動ナンバリングにします。 主キーを文字にした場合、手っ取り早く「あるかないか」だけを調べるなら、Selectして結果があるかないかでみます。 | ||||
|
投稿日時: 2002-10-11 10:21
行のカウントは DataGrid.Items.Count で取得できるかと。DataGridならですが・・・ 細かい突っ込みで申し訳ないですが 上述のE.Item.Cells.Countですけど とれるのは行でなくで「列」数(カラム数)ですね。 縦の方が行、横の方が列ですね。 なんか小姑みたいな書き込みで申し訳ないです。 それと、キーの書き換えですけどJittaさんの言うとおり 基本的には修正しないのがよろしいかと。 しかし、キー以外のフィールド「だけ」書き換えられるなんて謎ですね。 SQLのUpdate文のSET句にキーのフィールドが入っていないとか? Keyフィールドがtest1とかだったら Update Table1 SET test2=@test2,test3=@test3 where test1=@test1 とかで。 [ メッセージ編集済み 編集者: Eins 編集日時 2002-10-11 10:22 ] [ メッセージ編集済み 編集者: Eins 編集日時 2002-10-11 10:35 ] | ||||
|
投稿日時: 2002-10-11 10:25
Jittaさんの言うように、主キーの変更なんてことはやってはいけません。
変更したくなるような項目は主キーではありえないので。 で、ちょっと気になった点。 Jittaさん: > 主キーは、たいていは数字にします。 たいていは、の範囲が見えませんが・・・私の感触では数字以外のほうが多いような。 商品コードだとか品番だとか、主キーになりそうなものは結構あります。 場面によりますよね。 > 私はシーケンスを使いたくないので、「Select MAX(ID)+1」で、 > 現在使用されている最大値の次を取ります。 これは、カーソル開くときは気をつけないといけませんね。 OracleのシーケンスやSQL ServerやAccessの自動ナンバリングは大丈夫ですけど。 | ||||
|
投稿日時: 2002-10-11 10:56
便乗で質問です。
データの意味的に文字列が主キーになり得ることは多いかと思います。 まりりさんの挙げられている「商品コード」などはその典型です。 で、いつも悩むんですが、文字列を主キーにするというのは実行性能上の問題はあまり引き起こさないのでしょうか? 特に複数文字列の組み合わせで主キーとなる場合、例えば「店コード」(文字列)と「商品コード」(文字列)の組み合わせで一意になることが分かっている場合には、データの構造的にはそれで十分だとは思います。ただ、内部でこっそりと、その組み合わせに一対応する数値型キーを振ったほうが他テーブルとの結合処理が早いんじゃないかなーとか、悩んでしまいます。構造的には冗長なんですけど。 #資源が尽きるまでの寿命次第では選択の余地が無い場合もあるかも知れませんが 基本的にはこの辺の実装に関してはDBMSによって違うでしょうし、考えるだけ無駄なのかも知れないですが、「文字列同士の比較評価が何度も何度も走るというのはどうかなー」と思うことがしばしばです。 皆さんは、この辺りはどうなさっているんでしょう?「冗長でも基本的に数値IDを必ずセットする」派の方や「余分なものは極力定義しない」派の方のご意見をお聞きしたいです。 | ||||
|
投稿日時: 2002-10-11 11:09
冗長でも基本的に数値IDを必ずセットする
構造的に意味がないため、そのような手法は考えたことはないです。 余分なものは極力定義しない 余分なものが数値IDを指すのであれば、上記の理由のより 絶対に定義しません。 | ||||
|
投稿日時: 2002-10-11 11:10
このスレッドの趣旨から外れてきていると思いますので、 新しくスレッドを立てられてみてはいかがでしょうか? (他の方の意見を求めるならなおさら、ですね) その際、参照元記事URLにこのページを指定してあげれば すんなり話を持ち込めると思いますよ。 | ||||
|
投稿日時: 2002-10-11 11:24
プラットフォーム非依存の話だと思うので、「冗長な主キーを設定するか」に関しては、悩んだ挙句EngineerLife会議室の方にスレッド立てました。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=2352&forum=16&0 です。 アドバイス有り難うございました>まゆりんさん |
1|2|3
次のページへ»