- PR -

シーケンスと採番テーブルの選択

1
投稿者投稿内容
sumin
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 93
投稿日時: 2004-10-22 18:21
シーケンスオブジェクトと採番テーブルの中でどっちか選択する場合、その判断の基準は何でしょうか？また各物のメリットとデメリットは？
platini
大ベテラン
会議室デビュー日: 2002/12/03
投稿数: 193
投稿日時: 2004-10-22 18:26
シーケンスはDBMS依存っぽいので、
マルチDBMS対応にするつもりなら採番テーブル・・・でしょうか。
いーた
大ベテラン
会議室デビュー日: 2004/07/12
投稿数: 154
お住まい・勤務地: 東京
投稿日時: 2004-10-22 18:43
単純に連番を採番するだけなら迷わずシーケンスを採用します。
DBMSの乗り換えがあったとしてもシーケンスの移行は大した手間ではないと思います。
手軽に2重採番を防止できるので積極的に採用しても良いと思います。

逆に英数字が混在していたり、採番する値に特殊な規則性がある場合は採番テーブルになると思います。

未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2004-10-22 23:56
引用:

シーケンスオブジェクトと採番テーブルの中でどっちか選択する場合、その判断の基準は何でしょうか？また各物のメリットとデメリットは？

もうひとつ候補を出していいですか。私は「欠番探索」を採用しています。1, 2, 3, 5, 6 とあったら、実際のデータから欠番を探して、4 を採番するのです。

・シーケンス
　(良) アプリケーションで採番について考えなくて済む。絶対に重複しない。
　(悪) データを追加するまで、与えられる番号が分からない。欠番が起こる。

・採番テーブル
　(良) データを追加する前に与えられる番号が分かる。
　(悪) 管理が大変。バグの要因になりがち。設計者の手腕にかかっている。

・欠番探索
　(良) データを追加する前に与えられる番号が分かる。絶対に重複しない。欠番が起こらない。
　(悪) データ件数が多いと採番に時間がかかる。(でも、100万件くらいは余裕だよ！)


人工キーなら迷わずにシーケンスを使うけど、自然キーの場合はシーケンスは使いづらい面もある。たとえば伝票番号。シーケンスを使う場合、伝票入力で最後の登録ボタンを押すまで伝票番号を画面に表示させることができない。

採番テーブルに格納されているカウンタの値を「使用してからインクリメントする」プログラムと「インクリメントしてから使用する」プログラムが混在するだけで破綻する。採番テーブルの採番ルールについてチームなんできっちり決めてるのに、間違える馬鹿が後を絶たない。個人的に採番テーブルは二度と使いたくないです。

欠番探索は、シーケンスが使いづらい自然キー項目で使用してます。伝票番号とか。まず欠番確保して、画面に伝票番号表示。伝票入力を中止(ロールバック)しても問題なし。
sumin
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 93
投稿日時: 2004-10-25 14:44
皆さん、ご情報ありがとうございます。
因みに、その「欠番探索」ってのはどう実装するんでしょうか？下手に実装すると採番テーブルの悪い点＋パフォーマンス低下につながりそうな気がしますが。。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2004-10-25 15:06
テーブルをずらして自己結合すれば欠番は見つかるでしょ。他の人に同一番号を取られないように、別トランザクションで、取得した番号を予約テーブルに入れとく。予約テーブルへの挿入は基本的にコミットしない。

コード:
select NEW_CODE = min(t1.CODE + 1)
from (
  select CODE from [TABLE] union all
  select CODE from [RESERVE] (READUNCOMMITTED)
) t1 left outer join (
  select CODE from [TABLE] union all
  select CODE from [RESERVE] (READUNCOMMITTED)
) t2 on (t1.CODE + 1) = t2.CODE
where t2.CODE is null
1

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