私はこれまで主キーに auto_generated または Sequences を常に使用してきました。私が取り組んでいる現在のシステムでは、最終的にデータを分割しなければならない可能性がありますが、これは過去には必要ありませんでした。将来的にデータを分割する必要があるかもしれないことを知っていますが、データベースの組み込みシーケンスの代わりに PK に UUID を使用する利点はありますか? もしそうなら、比較的短いキーを安全に生成できる設計パターンはありますか (通常の長いキーの代わりに 6 文字とします e6709870-5cbc-11df-a08a-0800200c9a66)? テーブルごとに 36^6 個のキーは、私が想像できるどのテーブルにも十分すぎるほどです。
URL でキーを使用するので、簡潔にすることが重要です。
どのタイプのパーティションを計画しているのかわかりませんが (これは? )、主キーの設計を変更する理由がわかりません。古い分割テーブルが「生きている」(つまり、分割テーブルに行を挿入する可能性がある) 場合でも、複数のテーブル間でシーケンスを共有しても問題はありません。
情報が失われるため、128 ビットの UUID を 6 文字に減らすパターンはありません。ほとんどすべてのデータベースは、増分キーと呼ばれる代理キー戦略を実装しています。Postgres と Informix にはシリアル、MySql auto_increment があり、Oracle にはシーケンス ジェネレータが用意されています。あなたの場合、整数 ID を使用するのが安全だと思います。
この記事を参照してください:主キーの選択: 自然またはサロゲート? 利用可能な技術の議論のために