ここから本文です

データベースのテーブルのプライマリーキーに、オートインクリメントは多用します...

ケガの功名38さん

2020/1/1416:13:02

データベースのテーブルのプライマリーキーに、オートインクリメントは多用しますか?

.
近頃、Python - Django を勉強しているオールド・プログラマーです。
COBOL の時代から近頃は Java まで開発業務に携わっていますが、新しい言語も覚えようと、1ヶ月のセミナーを受講しているところです。
ところが、そこの先生が、テーブルのプライマリーキーを何でもかんでもオートインクリメントにしたがるのが、気になってしまっています。
オートインクリメントは便利ですので、私も、ちょっとした情報であれば主キーが単純な連番で構わないとは思います(履歴情報とか、ブログの書き込みとか)。
でも、マスタ情報やビジネス上の証跡として重要な情報であれば、もう少しルール化された採番がされるのが普通でないかと思うのです。
とはいえ、私も、自分の業務経験以外の見識は乏しいもので、近頃の新規開発ではそんな感じなのか、とも思い質問する次第です。
よろしくお願いします。

補足多くの有益なご意見、ありがとうございます。とても参考になります。
質問に書いた様にオートインクリメントの利便性は認めた上で質問させて頂いております。
単に、私がこれまで経験した現場で、オートインクリメントが多用されていなかった所からの質問です。
また、セミナーなので簡便に、というのは重々承知です。あくまで観念論です。

ひとつのポイントとして、一意なキー項目が、システム内部で使われるだけでなく表に出て、そこに業務要件が課されているかどうかでも違って来るかと思われます。
その場合でも、PKは連番にして別途一意キー項目を設けるという手法はありますが、一意性が求められる以上は、実装上の手間は大差ない様にも思われます。
重複を許して後で名寄せするというのも一つの方策ですが、それはデータ移行等限られた局面でのお話しの様にも思われます。

正解はないでしょうけど、あと少し、多くの方からご意見を伺い勉強させて頂きたく、おつき合い頂ければと存じます。

閲覧数:
62
回答数:
6
お礼:
100枚

違反報告

ベストアンサーに選ばれた回答

プロフィール画像

カテゴリマスター

nora1962jpさん

2020/1/1500:36:52

RDBの理論的にはテーブルに「自然キー」と「サロゲートキー」両方を「候補キー」として持っても何の問題もありません。テーブル分割する必要もない。

で、その場合「サロゲートキー」を主キーにしたほうが不変性を担保しやすいというのはあります。
RDBだと「外部キー」として使っている項目の値の変更は影響が大きいので避けたい。

最初に「コード設計」時に見通していた時より規模が大きくなった場合や企業合併時の「社員番号」のように見直しせざるを得ない場合があるので。

以前の汎用機やオフコンのCOBOLのシステムだと実装上「コードの桁数は必要最小限の桁数が望ましい」「コードとしてわかりやすいのがいい」という考えもあったと思いますが、「自然キー」「サロゲートキー」の整理を行えば話が変わってくると思います。

ただ、「サロゲートキー」が常に「auto_increment」である必要はないので、RDBMSによってはInsertされるデータのブロック(primary keyのインデックス含む)の競合を避けるための工夫を行う例はあるようです。

  • nora1962jpさん

    2020/1/1513:01:44

    > ユニーク性は保証されるけど、連番性は保証されないんですよね。

    これは「シーケンス」でも「オートインクリメント」でも保証がありません。
    Oracleの「シーケンス」がセッションに払い出す単位がデフォルトで1ずつでないので目立つかもしれませんが、どちらもトランザクションをロールバックすれば「連番」にはなりません。
    Oracleに「オートコミット」というモードがないのもあるかも。

  • その他の返信を表示

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

質問した人からのコメント

2020/1/21 01:23:54

皆さま、有益なご回答ありがとうございました。
また、追加の質問にも多くの方にお答え頂きありがとうございました。
正直言って、想定外の回答が大多数でしたが、でも、大いに勉強させて頂きました。

BAは、「自然キー」、「サロゲートキー」という、概念としては理解していましたが、用語としては初耳だったもので、nora1962jpさんに。

ベストアンサー以外の回答

1〜5件/5件中

並び替え:回答日時の
新しい順
|古い順

プロフィール画像

カテゴリマスター

iru********さん

2020/1/1509:22:32

ご質問の趣旨とはチョットずれますが...

ORACLE の SEQUENCE に連番性を期待して失敗した例を見たことがあります。

DBMS運用中は問題なかったのですが、DBサーバーのリブートで連番が飛んで、欠番ができてしまいました。

ユニーク性は保証されるけど、連番性は保証されないんですよね。

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

プロフィール画像

カテゴリマスター

qq_********さん

2020/1/1419:27:23

※補足があったので回答を書き直したが、内容に大差はないし、他の回答者とほぼ同じ意見なのでご容赦を。


AUTO INCREMENTされるIDって、それだけで「値がユニーク」かつ「値が小さい程古い」事が保証されるので、わざわざ別途「ルール化された採番(オレオレルール)」を利用するメリットが無いんだよね。


> 一意なキー項目が、システム内部で使われるだけでなく表に出て、そこに業務要件が課されているかどうか

それはちょっと違うと思う。

ご自分でも補足に書いた通り、表に出す「ルール化された採番」が必要なら、別途そういう情報を保持するカラムを作るなり、(RDB的な考え方なら)別テーブルに保持してIDで紐付ければ良い。

例えば、人の目から見て分かりやすいIDが欲しいだけであれば、DBではなくアプリレベルで、AUTO INCREMENT値を元にそういう値を、(種とするIDは分からないよう)生成する処理を作っても良い。


> 実装上の手間は大差ない様にも思われます。

本当にそうだと言えるかな?

例えばウェブ系など、毎秒何クエリも走る環境で、アプリとDBとでユニーク値の整合性を保つ事って、考えている程簡単ではないと思うけどね。

例えば、UNIQUE属性だけを付与したカラムでオレオレルールを採用するとして、生成した値の整合性を保つためには、アプリレベルとDBレベルとを包括した厳密なトランザクション処理が必須となる。

仮にできるとしても、わざわざ時間をかけてそういう仕組みを別途実装するメリットって何だろう?


DB設計には、仕様変更にも応じられる「柔軟性」も要求されるが、プライマリキーは後から簡単にホイホイと変えるべきものではないのだから、そこにオレオレルールを適用するメリットがない。

逆に聞きたいけど、具体的にはどういうメリットがあるのかな?

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

アバター

ID非公開さん

2020/1/1417:35:50

多用しますね。

体系化された(人に可読な、あるいはバーコードとして使うような)IDを用意することはもちろんありますが、それはDBテーブルの主キーとしてのIDとは大抵別のフィールドに入れます。

例えば、既存の古いシステム(人力運用も含む)からの移行で、あるべきIDが振られていなかったり、ID採番がルールから逸脱している、採番にカブりが生じている、あるいは同じものに複数のIDが振られている(重複レコード)場合もありますので、そういうモノは一旦そのままDBに受け入れるほうが、業務上の支障が少ないことが多いです。(名寄せ等はあとでゆっくりやる)

そうでない、新規システムでも、ID体系をやっぱり途中で変えたくなる場合が発生しますので、新旧のIDが、DB上の機能制限のないフィールドで共存、あるいは別フィールドで管理できるほうが、楽です。

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

kon********さん

2020/1/1417:26:23

速い設計・実装・改善のサイクルを中心に据える最近の開発の潮流では、
主キー設定の目的はテーブル間の高速結合という位置づけであり、
設計に時間のかかる全体設計(採番ルールなど)は比重が軽くなります。
まして、セミナーでの説明なので、PKをじっくり設定するよりも
自動的に採番されるオートインクリメントの方が簡単ということでしょう。

もちろん、あらかじめ決まっているのであれば使っても構いませんし、
必要に応じて後から追加するのでも構いません。
また、大規模システムであれば整合性がいるでしょうから
その場合は必ずしも軽視すべきでないと思います。

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

プロフィール画像

カテゴリマスター

nan********さん

2020/1/1416:51:49

私も特に避ける理由がなければ連番を使う派ですね。
ユニーク保証ですし、何と言っても番号管理を別途行わなくてよくなります。連番管理を行うには必ず何らかのロック機構が必要になり、そこがボトルネックになりかねませんので、DBMSのAutoIncに任せるのが一番いいでしょう。

ルール化されたコードが必要なら、プライマリキー以外でそう言った項目を持てば良いだけの話ですし、そう言ったコードをプライマリや外部キーに持てば二度と変更することができなくなり、何かと問題になる可能性があります。

これって別に最近に限った話ではないと思いますけどね。

返信を取り消しますが
よろしいですか?

  • 取り消す
  • キャンセル

あわせて知りたい

みんなで作る知恵袋 悩みや疑問、なんでも気軽にきいちゃおう!

Q&Aをキーワードで検索:

Yahoo! JAPANは、回答に記載された内容の信ぴょう性、正確性を保証しておりません。
お客様自身の責任と判断で、ご利用ください。
本文はここまでです このページの先頭へ

「追加する」ボタンを押してください。

閉じる

※知恵コレクションに追加された質問は選択されたID/ニックネームのMy知恵袋で確認できます。

不適切な投稿でないことを報告しました。

閉じる