こんにちは。

"Jun Akita" <j-akita@xxxxxxxxxx>さんの
<20031217144013.70BA.J-AKITA@xxxxxxxxxx>
"[mysql 08526] Re: MySQL でユニークキー"


> で、AUTO_INCREMENT というのはシーケンスのように（論理的に）無限ではない
> ので「なんとなく気持ちが悪い」と思った次第です。
> 無限ではないと言っても、実際には無限といっても差し支えないですし、シーケ
> ンスにしてもディスク容量等に引っ張られて結局は無限ではないわけですから、
> 良く良く考えてみるとあまり悩む必要がないような気がしてきました。

　oracleのシーケンスは10の27乗が最大値のはずです。これは２進数89ビット程
度です。上限は存在しますが、実用上無限と考えられている訳です。
auto_incrementな bigintのフィールドも64ビットの上限は存在しますが、実用
上無限という点ではoracleのシーケンスと同様でしょう。

　この手の事は、感覚で判断するのではなく、理性と言うと少々大袈裟、計算に
よって判断する事が宜しいでしょう。auto_incrementなbigintフィールドを主キー
とすれば、毎秒100万レコードを挿入するとしても58万年位は持つ計算になりま
す。oracleのシーケンスなら31兆年ですね。58万年では不十分、31兆年なら十分、
でしょうか？


> > 日付だけでまずいという事でしたら、例えば日付＋数値フィールドを主キーにし
> > たらどうでしょう？？
> > 同一時刻の書き込みは、多くても大した数ではないでしょうから、これで少しは
> > 安心できるかな？って気がしまして・・・ｗ
> 
> えっと、考え方は渡辺さんと同じだと思っています。
> ですが、「数値フィールド」に AUTO_INCREMENT を使ってしまうと（論理的に）
> 有限だなぁと。

　私見とすれば、時間のみを主キーにする事も十分にアリでしょう。ミリ秒、10
ミリ秒程度の粒度を持つ時間型なら、ですが。MySQLの timestamp型は粒度に問
題があります。 DBアクセスのエラーハンドラ中に、一意違反の場合は再行する
コードを追加するだけです。

　再行を前提としているなんて贅沢は出来ないとか、再行が再行を呼んでしまう
とかの、忙しいアプリケーションであれば勿論その様な手は禁じ手でしょう。エラー
ハンドリングを一切行っていない、なんかなぁなアプリケーションにも採用の余
地は無いでしょう。ケースバイケースですね。



　　　　松枝知直　　　　<tomom@xxxxxxxxxx>
　　　　　　　　　　　　http://www.argus.ne.jp/~tomom/