SELECT SYS_GUID() FROM DUALエンティティが作成されるたびに呼び出す継承されたコードがいくつかあります。これは、挿入ごとに Oracle に対して 2 つの呼び出しが行われることを意味します。1 つは を取得するためのものGuidで、もう 1 つはデータを挿入するためのものです。
これには正当な理由があると思います。たとえば、Oracle の Guid はシーケンシャルにすることで大量の挿入用に最適化されている可能性があるため、過度のインデックス ツリーの再調整を回避しようとしている可能性があります。
クライアント上でSYS_GUID独自に構築するのではなく、使用する理由はありますか?Guid
すでに提供されている場合は、自分で巻く必要はありません。また、最初に取得してから挿入する必要はありません。挿入するだけです。
create table my_tab
(
val1 raw(16),
val2 varchar2(100)
);
insert into my_tab(val1, val2) values (sys_guid(), 'Some data');
commit;
主キーのデフォルト値として使用することもできます。
drop table my_tab;
create table my_tab
(
val1 raw(16) default sys_guid(),
val2 varchar2(100),
primary key(val1)
);
ここでは、シーケンスを使用するために before insert トリガーを設定する必要はありません (または、ほとんどの場合、val1 やそのコードへの入力方法を気にすることさえあります)。
シーケンスのメンテナンスも増えました。システム間でデータを移動する際の移植性の問題は言うまでもありません。
しかし、シーケンスはより人間に優しいものです (数値を見て使用することは、生の値の 32 16 進バージョンよりもはるかに優れています)。シーケンスには他にも利点があるかもしれません。私は大規模な比較を行っていません。最初にいくつかのパフォーマンス テストを実行することをお勧めします。
懸念事項が2つのデータベース呼び出しである場合は、ステートメントSYS_GUID()内で呼び出すことができるはずです。句をINSERT使用してOracleが生成した値を取得することもできます。これにより、アプリケーションでその値を使用できるようになります。RETURNING
SYS_GUID は主キー列のデフォルト値として使用できます。これは多くの場合、シーケンスを使用するよりも便利ですが、値は多かれ少なかれランダムであり、シーケンシャルではないことに注意してください。プラス面では、ホット ブロックの競合が減少する可能性がありますが、マイナス面では、インデックスの挿入もあちこちに発生します。通常、この方法はお勧めしません。
参考までに ここをクリック