idをautoincrementして何が悪いの？

idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで

[nannan12]

前半はIDの話じゃないじゃん。RESTの設計にIDを使うかどうかが争点であって、こんなデメリットはスラグを設定したら済む話。

[dot]

ナチュラルキーとサロゲートキーの違いが良くわかってないようにも見受けられる。例示された連番の弊害はわかるけど、それはシステムの都合であってRDBの設計は別という文化で育ってきたのでピンと来ない所もある。

[daibutsuda]

Railsだと標準でCSRFトークンが入るので、当てずっぽでPOSTとかしようとしても404返るよ。メリットは設計がシンプルになり保守が容易になることでは？

[NetPenguin]

DBの主キーの話だと想定して、MySQLだとクラスタ化インデクスなので連続している方が良さそう https://techblog.raccoon.ne.jp/archives/1627262796.html あとUUIDいっぱいで通信路を圧迫しちゃったというのを、10年ほどまえにやらかした。

[daira4000]

いいとこ取りのULIDが都合良いんじゃないすかね

[peketamin]

露出するIDと内部で割り振る通し番号はまた別の話のような

[raamen07]

こういうの額面通りに間に受けてわけわからん設計しだす人出てくるから嫌。

[crexist]

auto increment の利点は生成された順にソートしやすい、わかりやすいというのがあるとは思う。ただ、他のブコメにあるように ULID で代替はできそう

[maninthemiddle]

挙げられてない理由で単なる連番だとIDを指定するようなUIでtypoがそのまま通ってしまいやすくなると言うのもある。1437を入れるはずなのに1347って打っちゃうのは非常にありがち

[mohno]

UUIDはちょっと……と思ったら、↓ULIDなんてのがあるんだね。最近、そういうプログラムを書いてないけど（定期）

[moneyshark]

uuid と autoincrement

[t2y-1979]

[[database][design][security][performance]

[honma200]

挙げられたことはUUIDv0とかで確かに保証されるが、autoincrementがダメというわけでもない。最後のものはそうなったら同じテーブル内でのPKが衝突するからエラーになるんでは？複数のDB上で同じテーブルならRDBMSがエラー出

[pascal256]

（保証出来ないのに）連番をつい期待してしまう、とかもあるかなー。あと超高負荷時に問題がでるからUUID派だったけどクラスタインデックスの話もあるから、自分の中にまだ正解が無い…

[ed_v3]

ケースバイケースだと思うけどタイトル見た時ここまでずれた論点だとは思わなかった。

[hamaco]

要件によりそう。ただまあこの記事に書かれているのはURLの話とDBの話が混ざっているのでDBがautoincrementでURLには違うキーを使うとかあるしまあ。

[sotarok]

要件によるけど、会員IDのようなもののランダマイズの利点については同意だな〜。(関係ないけど某国産SNSでURL 1つずつincして見てくと社の関係者と友人順に利用が広がっていく様がわかって面白かったよ、その昔)

[luccafort]

autoincrementなIDが一概に駄目とも思ってはいないけどただ連番IDだとこういうことされるよね？は知識として知っておきたいし、それに変わるID形式が生まれたりするのはいいことなんだろうと思う。ULIDは知らなかった。

[numtostring]

ULID がいいな。

[sisya]

内部IDと表示名とユーザIDは全部別のものであると認識しないと事故が起こる。筆者はその辺りがとても危うく感じる。もう少し言葉の定義を厳密に認識し直した方がいい。

[buzztaiki]

ブコメでいくつか容量の話がでてるけど、UUID や ULID もバイナリのまま扱えば128ビットだよ。

[versatile]

url の id を db の id にする人はこの時代流石にもういないとは思うが

[n314]

商品idを商品コードにしようとしたら、オペレーターがいつもidを使っていてアルファベットを入れられると作業効率がめっちゃ落ちるから数字だけにしてくれとかあったな。uuidだと効率が落ちるどころの騒ぎではない。

[pmint]

フレームワークを否定する人と同じこと言ってる。「PDO::prepareを使うと、発行されたSQLが分からない」みたいな。無能扱いされるけど、それはそれで一理ある。「〇〇を使えばこれ全部できます」って文章にするといい。

[kabuquery]

スクレイピング対策は別な話の気がするけど

[ducktoon]

連番で管理しつつURL用にuuidっぽいやつを別カラムに持つようにしてる。連番は開発者にとってわかりやすい(一番重要)のと、DB効率が良い(らしい)

[kotatsuhal]

こういった疑問をスルーせず出力したことを評価したい！周りに指摘してくれる人がいないとなぁなぁになって後で後悔するやつだから。

[rdrk]

スター大量についてるけど、ほんとにRailsは既存レコードを"POST"で取ってCSRFには"404 not found"を返すの？

[Wafer]

uuidでもulidでもDBを水平分割して運用してたら一意性を確保できないかもしれない気がするんだけど気のせい？ブックマークコメントを見渡してもあまり大規模なアクセスを想定していないように見える

[vuy]

DBで採番するからSPoFになる的な話かと思ってたらただのお気持ち投稿だった。 / この記事投げつけたいな。 https://zenn.dev/j5ik2o/articles/a085ab3e3d0f197f6559

[Seitekisyoujyo]

連番idやらないと複合ユニーク複合プライマリキーのアップデートが面倒だし、それで外部キーを指定したいと思った時に一手間かかる。複合ユニークやるぐらいなら連番id設けた方が絶対的に実装楽だと思う。

[spark7]

UUIDをプライマリキーにすると効率悪くなるとか前に言ってたよな。

[kamm]

悪いとする理由が微妙じゃないか…？bigint使っても8バイトで済むという効率性もあるし

[b-wind]

はてブでは ULID を推す声が多い

[takeshi]

ふたつほど言いたいことがあるが、また今度ね。

[yug1224]

IDはULID使いたい

[tacamula]

プロダクトの状況で使い分けという身も蓋もない結論にしかならんのでは。あとログインユーザ自身のIDはセッションで判定すべきで、IDの予測を難しくくるのは場当たり的かな。