auto_increment制約の必要性を教えてください。


MySQLをインストールした時に、「mysql」というサーバ側で使うデータベースにテーブルが17ありましたが、
auto_increment制約を使っているテーブルは1つだけでした。
ということから、auto_increment制約はあまり使うべきではないのかと考えました。
ユニークな値が存在するときに、それとは別に連番を振る必要性が分かりません。

テーブル設計において、auto_increment制約を使ったほうが良い状況はどんなときでしょうか?

回答の条件
  • 1人2回まで
  • 登録:2007/11/13 04:41:51
  • 終了:2007/11/14 02:30:13

ベストアンサー

id:KUROX No.4

KUROX回答回数3542ベストアンサー獲得回数1402007/11/13 12:22:44

ポイント50pt

>情報不足でしたが、この場合顧客名がユニークならそれを主キーにしたいという話です。

>顧客名が重複する場合は、電話番号などを主キーにするべきなのかと悩んでいます。

顧客名がいくらユニークでも、主キーにするのは妥当でないと思います。

得意先別単価台帳とかのフィールドに、顧客名が入ることになるので、妥当でないでしょう。

電話番号も、主キーにするのはいまいちですね。

電話番号が変わることもあるので、変わった場合の処理が1テーブルだけでなくて

他のテーブルにも波及してしまうので、設計としてはよくないでしょう。

顧客番号や顧客IDを主キーにしたいところですが、ユーザーさんがそれを意識したくないとかで

表に出せない場合は内部で命名規則を作る必要があります。その手段の1つとして、

auto_incrementを使うというのがあります。

>どんな構造のテーブルでも、auto_increment制約のフィールドを無理矢理用意することは

>可能ですが、

>極力意味のない連番を用意する構造に設計するべきではないかと考えています。

まあ、それは当然な話ですけど。

>テーブル設計において、auto_increment制約を使ったほうが良い状況はどんなときでしょうか?

積極的に使うべきものでないと思うので、使ったほうが良い状況は、使わないとシンプルに解決

できない場合だけでしょう。

普通に伝票番号とか通し番号をつけたいときに使うとかそういうのはありではないかと思いま

す。

id:Loups-garous

>顧客番号や顧客IDを主キーにしたいところですが、ユーザーさんがそれを意識したくないとかで

>表に出せない場合は内部で命名規則を作る必要があります。その手段の1つとして、

>auto_incrementを使うというのがあります。

こういう時は、まさにその通りだと思います。こういうことを聞きたかったです。

回答ありがとうございました。

2007/11/13 12:58:30

その他の回答(3件)

id:paraizo No.1

paraizo回答回数139ベストアンサー獲得回数102007/11/13 08:57:16

ポイント20pt

ruby on rails とかだと使いまくりですね。

確かにデータ自体がユニークなら問題が無いのですが、一意にしたいけどデータがユニークじゃないことは結構あります。

例えば掲示板の記事とかhttp://q.hatena.ne.jp/(1194896511)←とかです。

ただ、あくまでデータベース単位でしか一意性を保障してくれないのでスケーラビリティーを求めるなら別の手段で実現するべきだと思います。

id:Loups-garous

RoRでは、たしかに主キーのフィールド名など決まりごとが多いのでオートインクリメント制約だと思います。

>例えば掲示板の記事とかhttp://q.hatena.ne.jp/(1194896511)←とかです。

この数字は今調べたところ、auto_incrementではなくタイムスタンプでした。(2007-11-13 04:41:51です)

どうやらはてなも、少なくとも記事の識別にはauto_incrementを使ってなさそうです。

ブログの記事など多数の投稿が予測されるシステムでは、auto_incrementを使ってもいいと思うのですが、

ユーザアカウントとタイムスタンプの複合キーで代用できると思います。

DBサーバをテーブル単位で分散した場合は、複合キーや別のアルゴリズムで主キーを生成する必要がありそうですね。

回答ありがとうございました。

2007/11/13 10:54:33
id:un0 No.2

un0回答回数651ベストアンサー獲得回数322007/11/13 09:36:09

ポイント10pt

>ユニークな値が存在するときに、それとは別に連番を振る必要性が分かりません。

その場合無理に使う必要性はないですね。

ユニークな値が存在しない場合にauto_increment制約を使えばよいと思います。

例えば、

社員テーブルなら社員番号があるので必要ないです。

しかし、

顧客テーブルとなったら顧客番号はどうしますか?

番号付けのルールが決まっていますか?

決まっていればそれに従えばよい。

決まっていない場合auto_incrementを使うと楽ですね。


参考になれば幸いです。

id:Loups-garous

>顧客テーブルとなったら顧客番号はどうしますか?

>番号付けのルールが決まっていますか?

情報不足でしたが、この場合顧客名がユニークならそれを主キーにしたいという話です。

顧客名が重複する場合は、電話番号などを主キーにするべきなのかと悩んでいます。

どんな構造のテーブルでも、auto_increment制約のフィールドを無理矢理用意することは可能ですが、

極力意味のない連番を用意する構造に設計するべきではないかと考えています。

回答ありがとうございました。

2007/11/13 11:01:34
id:shiroxcom No.3

しろっくす回答回数140ベストアンサー獲得回数52007/11/13 10:15:44

ポイント10pt

例えば、10000件のデータが格納されていたとして、

その中でユニークなIDを作って10001件目のデータを新たに格納するとします。

その時、auto_incrementがもし無かったら、一度全データをselectして、

今から入力しようとしているIDがユニークかどうか調べなければいけなくなってしまいます。

ユニークIDが簡単な数字で構わない場合、自動でユニークIDを振っていってくれることは

コーディング量を減らすことと、余計なselectをしなくて済むことに貢献することになります。

id:Loups-garous

この場合、ユーザのアカウント名等とタイムスタンプを複合キーにして、一意なものにしたいと考えています。

今から入力しようとしているユーザが二重投稿などをした場合は、主キーの制約によって蹴られるので問題ないと思いました。

このような理由から、auto_incrementを使う理由がよく分からなくなってしまったのです。

回答ありがとうございました。

2007/11/13 11:04:37
id:KUROX No.4

KUROX回答回数3542ベストアンサー獲得回数1402007/11/13 12:22:44ここでベストアンサー

ポイント50pt

>情報不足でしたが、この場合顧客名がユニークならそれを主キーにしたいという話です。

>顧客名が重複する場合は、電話番号などを主キーにするべきなのかと悩んでいます。

顧客名がいくらユニークでも、主キーにするのは妥当でないと思います。

得意先別単価台帳とかのフィールドに、顧客名が入ることになるので、妥当でないでしょう。

電話番号も、主キーにするのはいまいちですね。

電話番号が変わることもあるので、変わった場合の処理が1テーブルだけでなくて

他のテーブルにも波及してしまうので、設計としてはよくないでしょう。

顧客番号や顧客IDを主キーにしたいところですが、ユーザーさんがそれを意識したくないとかで

表に出せない場合は内部で命名規則を作る必要があります。その手段の1つとして、

auto_incrementを使うというのがあります。

>どんな構造のテーブルでも、auto_increment制約のフィールドを無理矢理用意することは

>可能ですが、

>極力意味のない連番を用意する構造に設計するべきではないかと考えています。

まあ、それは当然な話ですけど。

>テーブル設計において、auto_increment制約を使ったほうが良い状況はどんなときでしょうか?

積極的に使うべきものでないと思うので、使ったほうが良い状況は、使わないとシンプルに解決

できない場合だけでしょう。

普通に伝票番号とか通し番号をつけたいときに使うとかそういうのはありではないかと思いま

す。

id:Loups-garous

>顧客番号や顧客IDを主キーにしたいところですが、ユーザーさんがそれを意識したくないとかで

>表に出せない場合は内部で命名規則を作る必要があります。その手段の1つとして、

>auto_incrementを使うというのがあります。

こういう時は、まさにその通りだと思います。こういうことを聞きたかったです。

回答ありがとうございました。

2007/11/13 12:58:30
  • id:chuken_kenkou
    テーブル設計の上で、行を一意に識別できる通番を持ちたい場合があります。
    そういった場合、ユーザ側で通番を生成するには、「SELECT MAX(キー) FROM 表名」で得たキー値を
    +1するといった方法でキー値を作りますが、最大値を得て+1のキー値で格納するまでの間に、
    別ユーザで先に同じ同一キー値で格納されるといったことが生じる場合があり、これはシステム設計する
    上で大きな問題になることがあります。
    これを容易に実現できる方法として、「シーケンス」という機能があり、標準SQLでも規定されたと思い
    ます。
    いくつかのRDBMSでは、「CREATE SEQUENCE」でシーケンス名を定義して、例えば社員番号が「入社
    年度+通番」といったケースなどで活用できます。MySQLのAUTO_INCREMENTは、シーケンスの簡易
    版(値の範囲を指定できず、増分も+1だけ)です。

    AUTO_INCREMENTも、MyISAMなどでは、「ユーザID+通番」、つまり

    CREATE TABLE LOG_TBL
    (USERID CHAR(5),
    SEQNO INT AUTO_INCREMENT,
    ~中略~
    PRIMARY KEY(USERID,SEQNO))

    というような、ユニークなキーを構成する2番目、3番目といった列にすることが可能です。
    トラフィック量が少ないシステムなら、「 ユーザID+日時」でもユニークになるかも知れませんが、短時間
    で多量にINSERTが発生するような場合は、「日時」が絶対、重複は発生しないとは言えません。

    一方、RDBMSによる自動採番は、複数ユーザからの同時アクセスがあっても、最大値+1のキー値を
    容易に得られる反面、ロールバックが発生すると、欠番ができるという問題もあり、欠番が許されない
    ものには適用できません。この場合は、ユーザ側で何らかの仕組みを作る必要があります。

    また、コード体系などが変わる可能性が高いテーブルなどには、敢えてそのコードでなく、通番を主キー
    にする場合もあります。これは、「サロゲートキー」と呼ばれ、そういう設計方法を好む人もいます。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません