UUID (Universally Unique Identifiers) は、テーブル エントリを一意に識別するためにデータベースなどで使用される 128 ビット値です。 これらは、ハイフンで区切られた 5 つのグループに分割された 16 進文字列として表されます (例: 09fe49b3-4d2b-471c-ac04-36c9e706b85f）。 がある 多数 ディスカッション データベースにおける UUID の長所と短所について - それらは分散システムに不可欠です。
したがって、マイクロサービスおよびマルチテナンシー アプリケーションでは、UUID の導入を検討する価値があります。 PHP フレームワークLaravelでのデータ型 BigInteger から UUID ( RFC 4122仕様の UUID バージョン 4 のソート可能なバリアント) への切り替えは迅速に行われます。まず、新しい特性を作成します。:
2aa7136d977617159be1834eaf40e871
次に、すべてのモデルを追加します:
2aa7136d977617159be1834eaf40e871
Laravel 9⁺ では、これはさらに簡単です。ここではすでにHasUuidsトレイトを使用する準備ができています。 あるいは、このフレームワークは、関連しているがまだ不明なデータ型ULIDのサポートも提供しています。
難しいのは、既存のデータの移行です。 大まかに次のように進めることができます:
- すべてのテーブルに空の値を持つ新しい UUID 列を追加します
(それぞれがすべての主キー列と外部キー列に基づく) - UUID 値を新しい列に書き込みます
(昇順の主キーと更新された外部キーを使用) - 元の列を削除
- 新しい列の名前を変更
ここにはいくつかの課題があります: 移行プロセスには時間がかかり、新しい列がテーブルの最後に追加されます (考えられる解決策:列を並べ替えます)。 より直接的な方法は、列を直接変換することです。
それを入れたら PostgreSQL 1 つ目は、(もちろん、以前のバックアップの後) 次のクエリを実行できます。たとえば、(その前に、Z. 19/31 置換し、Z で独自の特別なルールを作成します。 37/39 add) から生成されたすべてのクエリをコピーします。:
2aa7136d977617159be1834eaf40e871
生成されたクエリを一緒に実行すると、短時間でデータベースを移行できます。 このように生成された UUID は v4 仕様に準拠していませんが、辞書的には前のエントリと同じ順序であり、新しい UUID と衝突しません (v4 の 3 番目のグループには常に 4, 移行されたバリアントでは常に 1 つ 0)、これは、新しい UUID が常に移行された UUID よりも大きいことも意味します。
その後、すべての Laravel キャッシュを削除することをお勧めします (php artisan cache:clear && php artisan route:clear && php artisan config:clear && php artisan view:clear && composer dump-autoload && rm -rf bootstrap/cache/*/*) および実行中のセッション (rm -f storage/framework/sessions/*） 空にする。 もちろん、すべてを Laravel 移行内で実装することもできます:
2aa7136d977617159be1834eaf40e871
変換後、代わりに将来の移行で使用します bigIncrements また。 bigInteger それから uuid:
2aa7136d977617159be1834eaf40e871