MySQLでauto_incrementをつかわないやり方

例えば、ブログサイトのように記事をユーザーに投稿させる場合を想定します。MySQLでIDをauto_incrementを使って管理する場合、記事が削除され場合、IDが歯抜け状態になります。もういちどIDを打ち直してもよいのですが、それをすると、その記事に関連するコメントテーブルなどに影響がてできます。

一方で、それなら、はじめから、auto_increment使わないようにして、その場合は、IDではなく、何を基準にするのがベストなのか? という質問になります。

今考えているのは、

・insertした時の日付
・ユーザーid

で、レコードを特定するやり方です。良いのか悪いのかお手本がないので、なんともいえないのですが、他のかたがたの意見・やり方があれば、是非聞きたいと思います。

質問者からの補足コメント

• 

  ありがとうございます。他の方のやり方をお聞きするのは、かなりのお勉強になります。これまで、auto_incrementしまくっていたのですけど、auto_incrementしているidカラムが、限界に達した場合とか考えたら、歯抜けになっている部分が無駄に思えてきたのですけど、このあたりは、どうお考えでしょうか?

  No.1の回答に寄せられた補足コメントです。 補足日時：2017/08/11 22:56

No.2 ベストアンサー 回答者： sefp 回答日時： 2017/08/11 23:13

＞auto_incrementしているidカラムが、限界に達した場合とか考えたら、歯抜けになっている部分が無駄に思えてきたのですけど、このあたりは、どうお考えでしょうか?

MySQLの場合、auto_incrementの最大値は定義したデータ型に依存したのではないでしょうか？
やとしたら、そのデータ型を決めるのもDB設計の一環なんで、運用過程で新規作成されるデータがどのくらいあるかetc.を見積もって定義すべきでしょうね。

ただ、ふと思ったところでは、新規データも多いけど削除データも多い・・・というケースでは、確かに他の項目をキーにした方がええかもしれません。
ポイントは、運用でどういったデータの入り方・消え方するかですね。

この回答へのお礼

ありがとうございます。とても勉強になります。少なくても、これまでauto_incrementはしなければならないものだと思い込んでいましたので、削除が多い場合は、違うものをキーにしても問題ないということが分かりました。

お礼日時：2017/08/12 00:47

No.1 回答者： sefp 回答日時： 2017/08/11 22:46

＞MySQLでIDをauto_incrementを使って管理する場合、記事が削除され場合、IDが歯抜け状態になります。

逆に、IDが歯抜けになって何が困るのでしょうか？
感覚的には確かに気持ち悪いんですが、DB設計として
「削除のいかんにかかわらず、過去に投稿した履歴を管理するID」
という位置づけをすればスッキリしませんか？

ちなみにおいらがやった仕事では、画像DBで固定の画像名に連番つけて管理してました。
運用してるうち、確かに歯抜けのデータばかり増えて気持ち悪かったけど、後々の管理はめっちゃ楽でしたよ！

この回答へのお礼

ありがとうございます。他の方のやり方をお聞きするのは、かなりのお勉強になります。これまで、auto_incrementしまくっていたのですけど、auto_incrementしているidカラムが、限界に達した場合とか考えたら、歯抜けになっている部分が無駄に思えてきたのですけど、このあたりは、どうお考えでしょうか?

お礼日時：2017/08/11 23:03