人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

●質問者: Loups-garous
●カテゴリ:コンピュータ ウェブ制作
✍キーワード:MySQL インストール サーバ データベース ユニーク
○ 状態 :終了
└ 回答数 : 4/4件

▽最新の回答へ

1 ● paraizo
●20ポイント

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

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

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

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

◎質問者からの返答

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

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

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

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

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

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

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

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


2 ● un0
●10ポイント

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

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

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

例えば、

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

しかし、

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

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

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

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


参考になれば幸いです。

◎質問者からの返答

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

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

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

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

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

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

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


3 ● しろっくす
●10ポイント

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

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

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

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

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

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

◎質問者からの返答

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

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

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

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


4 ● KUROX
●50ポイント ベストアンサー

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

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

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

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

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

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

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

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

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

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

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

>可能ですが、

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

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

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

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

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

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

す。

◎質問者からの返答

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

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

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

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

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ