(現在 過去ログ47 を表示中)

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

[ 最新記事及び返信フォームをトピックトップへ ]

■7388 / inTopicNo.21)  Re[1]: SQL Server の IDENTITY について
  
□投稿者/ そら -(2013/01/22(Tue) 20:41:26)
    ご丁寧にお答えくださり、皆さんありがとうございます。
    すみませんが、もう1つ伺いたいことがあります。
    
    
    INSTEAD OF INSERTトリガが同時に複数、多重実行される可能性はあるのでしょうか?
    
    もしそのような場合、下記の定義では[ID]が重複してしまうと思うのですが、
    その様な状況を回避することは可能でしょうか?
    
    SQL Serverの処理速度から推測して、発生確率は低いと思われるのですが、
    リスクはあるように思えます。
    
    たびたびお手数をお掛けしますが、お願いします。
    
    
    > CREATE TRIGGER InsteadOfInsert on テスト表
    > INSTEAD OF INSERT AS BEGIN 
    > 	INSERT INTO テスト表( 
    > 		[ID],
    > 		[項目1],
    > 		[項目2]
    > 	)
    > 	SELECT
    > 		[newID],
    > 		[項目1],
    > 		[項目2]
    > 	FROM
    > 		inserted,
    > 		(select
    > 			case
    > 				when max( [ID] ) is null then 1
    > 				else max( [ID] ) + 1
    > 			end as [newID]
    > 		from	テスト表)a
    > END;

引用返信 [メール受信/OFF] 削除キー/
■7389 / inTopicNo.22)  Re[10]: SQL Server の IDENTITY について
□投稿者/ 尾形 -(2013/01/22(Tue) 21:48:15)
    だから
    > シビアな状況でなければ、お手軽に
    というわけです (^^;

    ちなみに、バッティングしたら
    桐(ODBC)から、エラーメッセージが返ってくるようで
    [再試行]で再繰上されています



    シビアな状況では、別テーブルで、端末毎に
    自前でオートナンバを振っています

引用返信 [メール受信/OFF] 削除キー/
■7391 / inTopicNo.23)  Re[11]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 07:37:17)
    尾形さん、ありがとうございます。

    > だから
    >>シビアな状況でなければ、お手軽に
    > というわけです (^^;

    そういう意味だったのですね。理解しました。


    > ちなみに、バッティングしたら
    > 桐(ODBC)から、エラーメッセージが返ってくるようで
    > [再試行]で再繰上されています

    INSERTとUPDATEがきちんと区別されるのですね。
    アドバイス、ありがとうございます。


    > シビアな状況では、別テーブルで、端末毎に
    > 自前でオートナンバを振っています

    サーバー上に1つだけの別テーブルを専有で開くわけですね。
引用返信 [メール受信/OFF] 削除キー/
■7393 / inTopicNo.24)  Re[2]: SQL Server の IDENTITY について
□投稿者/ 通りすがり -(2013/01/23(Wed) 08:39:53)
    そういう事が無いように順序立てて処理する仕組みがデータベースサーバー
    もし万々々が一の時は、主キーなんだからエラー出るでしょ

    INTEGER使うなら「サーバ側でID振って、桐側で必要時に再抽出する」に一票

    つーか、主キーはCHARで問題ないとオモ
引用返信 [メール受信/OFF] 削除キー/
■7395 / inTopicNo.25)  Re[3]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 14:37:53)
    通りすがりさん、ありがとうございます。

    データーベースサーバーとはそういうものなのですね。理解しました。
引用返信 [メール受信/OFF] 削除キー/
■7398 / inTopicNo.26)  Re[1]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 21:00:42)
    みなさん、ありがとうございました。

    おかげさまで、非常に勉強になりました。

    今後もぜひよろしくお願いします。
解決済み!
引用返信 [メール受信/OFF] 削除キー/
■7415 / inTopicNo.27)  Re[9]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/28(Mon) 21:11:54)
    2013/01/28(Mon) 21:13:54 編集(投稿者)

    今村さん、ご指摘ありがとうございます。

    ユーザーの表を使う前提なのですね。勉強になりました。
    ただ、私としてはユーザ名よりはコンピュータ名の方が、
    同一のサブネット内での重複が避けられる点で安全性が高いと考えました。
    無論、IPセグメントを越える様な規模では無意味なのですが。

    可読性と用心のために、かなり冗長な文字列になってしまっているのは、
    まさにおっしゃる通りです。まだまだ改善が必要ですね。

    なお、行番号を付加する目的は、「読み込み」も使えるようにする事でした。
    つまり読み込みの場合は、全く同一の日時値で複数行追加されるリスクが
    想定された訳です。
引用返信 [メール受信/OFF] 削除キー/
■7416 / inTopicNo.28)  Re[10]: SQL Server の IDENTITY について
□投稿者/ 今村 誠 -(2013/01/29(Tue) 09:37:38)
    そらさんこんにちは
    > なお、行番号を付加する目的は、「読み込み」も使えるようにする事でした。
    > つまり読み込みの場合は、全く同一の日時値で複数行追加されるリスクが
    > 想定された訳です。

    何から読む込むのか書いてありませんが、csvやアクセスのデータから
    一度桐の表に変換して、外部データベース用に加工してから、通常使用
    する外部データ表とするのがいいのではないでしょうか。

    2つ前のコメント No7371 の手続き名でいえば行挿入の日時値を関数で
    なく日時値加算を使い「0.1秒」毎に加算していけば1分で600件が
    1時間で36000件が8時間で288000件が1PCや1ユーザー名で追加可能で
    あり、22時の深夜や休日祭日に初期値を設定すればいつでも読み込みは
    可能です。
    通常の業務で支障なければ一番理想的な主キーになるのではないですか。
引用返信 [メール受信/OFF] 削除キー/
■7417 / inTopicNo.29)  Re[11]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/29(Tue) 13:56:29)
    今村さん、ありがとうございます。
    とても勉強になりました。
引用返信 [メール受信/OFF] 削除キー/

<前の20件

トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ

過去ログには書き込み不可

Mode/  Pass/

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -