1,000 万レコードになるデータベース テーブルがあります。auto_increment は使用したくありません。これにより、ユーザーがレコード数を知ることができるからです。それを競合他社に公開したくありません。私が見る問題は、UUID などを使用するとクエリのパフォーマンスが低下することです。
たとえば、これはノーノーです: http://domain.com/widgets?id=34345
競合他社がサイトをクロールして、私たちが持っているウィジェットの数を判断できるからです。このビジネス シールドはアプリ レベルで処理する必要がありますか?それともデータベース レベルで処理しても問題ありませんか? この状況で多くの人は何をしますか？使用しているデータベースは postgres ですが、ソリューションはまだデータベースに依存しないと思います。
GUID をキーとして使用します。この質問を見ると、なぜそれがOKなのかがわかります。GUID 番号のサブセットを使用することで回避できる場合がありますが、ビット サイズが小さいほど衝突が発生する可能性が高くなります。GUID は大きすぎず、数値として格納できる必要があります。キーの転送は 4 倍になりますが、それはほとんど関係ありません。
ストレージは、1,000 万行で約 120 MB 増える可能性がありますが、このような大きなサイズでは無視できるようです。GUID のパフォーマンスをテストして、不足していることがわかりましたか?
私はスラッグ ベースの URL を使用します。ここでは が一意であり、したがってインデックス フィールドがあり、さらにhttp://example.com/awesome-blue-widgetslugのような素敵な URL が得られます。ウィジェット名を小文字にしたり、スペースをハイフンに置き換えたりすることでスラッグを作成できます。私の Web フレームワークには簡単な機能があり、スラッグが既に取得されている場合は最後にインクリメントを追加するように拡張しました。slugify
ナメクジは一般的にパターンに一致します[a-z0-9-]+。また、ビジネス データを損なうことなく、自動インクリメントされた主キーを他のテーブルなどの外部キーで使用することもできます。