0

開示：私は「自然な鍵」の支持者であり、IDENTITY PKアプローチを嫌っています。しかし、私はライフスタイルの選択に対して「生きて生きる」アプローチを取っているので、ここで宗教的な議論はしないでください:)

唯一のキーが IDENTITY PK 列であるテーブルを継承しました。IDとしましょう。ID を参照するテーブルは多数あります。新しいエンティティを作成する意図されたプロセスは次のようです。

  1. テーブルに挿入します。
  2. 自動生成された ID を取得するには、scope_identity を使用します。
  3. 自動生成された ID を使用して、関連するテーブルに挿入します。

実際、エンティティを作成して ID を返すためのヘルパー ストアド プロシージャがあります。ただし、いくつかの問題があります。

ヘルパー ストアド プロシージャよりも先に進んで、それ自体が IDENTITY PK を持つ関連テーブルに行を作成する必要があるため、エンティティごとに途中でいくつかの自動生成された値を取得する必要があります。数百のエンティティを作成する必要があり、ヘルパー プロシージャは一度に 1 つのエンティティを処理するようにコーディングされています。

「IDENTITY PK」設計を使用してエンティティを一括製造する最良の方法は何ですか?

独自の「自然キー」設計を使用する場合、事前にキー値を生成できます。そのため、スクラッチ テーブルをロードし、外部キーが期待する順序でテーブルに INSERT するだけです。したがって、現在使用されていないことがわかっている一連の高い値の INTEGER 値 (IDENTIY 列の型と一致する) を見つけて、その時が来たら使用されないことを願っています。挿入します。これは良い考えですか？

4

1 に答える 1

0

特にMS SQL Serverについて話しているのですか?

IDENTITY 列がデフォルトで明示的な挿入を許可していないのは残念です。他の DBMS では、自動インクリメントであっても、その列に明示的な値を挿入する必要はありません。これにより、事前にキーを簡単に選択できます。残念ながら、SQL Server では、心配するSET IDENTITY_INSERTの不都合があります。

エンティティを作成して ID を返すためのヘルパー ストアド プロシージャがあります。

SCOPE_IDENTITY()を選択するのと同じくらい簡単なので、そのために sproc を使用するのは少しやり過ぎに思えます。多くの場合、最後の挿入の SCOPE_IDENTITY() を直接使用できるように各挿入を記述することで、明示的な選択を回避できます。

現在使用されていないことがわかっている一連の高い値の INTEGER 値を見つけて、それらが使用されないことを願っています [...] これは良い考えですか?

必ずしも非常に高い値である必要はありません。実際、これを頻繁に行うと、IDENTITY 値に多くの大きなギャップが生じることになりますが、これは一般的に回避したほうがよいでしょう。MAX(column)+1他の誰かがその間にそれらの値を使用したエラーをキャッチする限り、値を使用することもできます。または、select-max を実行してからトランザクションに挿入することをお勧めします。

于 2009-11-09T10:36:04.493 に答える