DBのテーブル設計 PKにuuidを使う場合の仮データ作成方法について

Question

DB、特にuuidを使っている人に聞きたいのですが、プライマリキーをuuid（またはulid）にしている場合、レコード生成後しかその値がわからないので、以下のような問題をどう解決すればいいのか教えてほしいです

例えばレコード生成前にデータを投入する仮データをSpreadsheetとかで管理する場合、そのuuidを他テーブルのリレーションキーとして使っているときに、なんかしら仮のIDをいれておかないとリレーション状態がわから無くてレコード管理ができないと思うんです

例えば下記サイトのように、他のカラムにそのカラムの一意性がわかるようなカラムを追加するなどの対応も考えています

4 整数の主キーを持つ

UUIDを使用していたり、それが意味をなさない場合（結合テーブルの場合など）でも、自動インクリメントの整数列を持つ標準的なidカラムを追加します。このようなキーがあると、グループの最初の行だけを選択するなど、特定の分析が非常に簡単になります。

また、インポートジョブでデータが重複してしまった場合、特定の行を削除することができるので、このキーは非常に役立ちます：

https://sisense.gaprise.jp/blog/0032

が、無駄にデータを増やしてパフォーマンスを悪くしているような気もしていまいち何がいいのかわからないので、知見のあるかた、このようにするといいよというのがあれば教えて下さい

Answer 1

uuidなんだからクライアント側で勝手に生成しちゃって、それをinsertすればいいのでは？
各々が勝手に作成してもぶつからないのがuuidの利点でしょう？

Comments

[aoju]

解答ありがとうございます

たしかにそうでした、データ作成時の gen_random_uuid 関数を使わなければいけない、と思い込んでいたのでuuid v4のロジックをクライアント側で使ってその値をそのままinsertすれば良さそうですね！

Answer 2

リンク先は、ナチュラルキーではなくサロゲートキーをお薦めしている訳です。

他のカラムにそのカラムの一意性がわかるようなカラムを追加するなどの対応も考えています
無駄にデータを増やしてパフォーマンスを悪くしているような気もして

１カラム増えた程度で、パフォーマンスが悪くなるような事はありませんし、結合まで考えると、UUIDよりサロゲートキーを採用する方が効率的だと思います。

レコード生成前にデータを投入する仮データをSpreadsheetとかで管理する場合、そのuuidを他テーブルのリレーションキーとして使っているときに、なんかしら仮のIDをいれておかないとリレーション状態がわから無くてレコード管理ができないと思うんです

仮では無くて、UUID以外の一意になるデータを決定しないと結局管理は出来ないですよ。
UUIDはあくまでメタデータとして考えると良いのではないかと思います。

Comments

[aoju]

解答ありがとうございます

> リンク先は、ナチュラルキーではなくサロゲートキーをお薦めしている訳です。

UUIDもそれを見ただけではなんのデータかわからないため、ナチュラルキーではなくサロゲートキーと認識しています
なので

> １カラム増えた程度で、パフォーマンスが悪くなるような事はありませんし、結合まで考えると、UUIDよりサロゲートキーを採用する方が効率的だと思います。

UUIDよりサロゲートキーを、という下りがわからないのですがたしかに１カラム増えた程度でパフォーマンスに影響が出ることもないのでカラムの追加を行ってみて、ありなしで比較してみようと思います

> 仮では無くて、UUID以外の一意になるデータを決定しないと結局管理は出来ないですよ。
> UUIDはあくまでメタデータとして考えると良いのではないかと思います。

こちらはmatukesoさんの提案でのクライアント側で先に生成してその値で管理すればいいような気がしましたが、あくまでUUIDをPKとしてではなくメタデータとしての管理をするメリットはありますでしょうか

※今回はたまたまPostgresqlを使っていて下記サイトからidにはuuidを推奨しているような記述を見て、 gen_random_uuid() という UUID v4 の生成関数も標準で提供されていたので、PKにしようとした経緯があります
https://siguniang.wordpress.com/2013/03/17/stop-using-numbers-as-ids-just-use-uuids/

[sazi]

uuidありきかと思って回答しましたけど、主キーにuuidを採用するか否かという趣旨の様ですね。

> 仮データをSpreadsheetとかで管理する
> クライアント側で先に生成してその値で管理すれば

クライアント毎のシステムなら理解できますけど、サーバーで管理するなら集中させないと色々不都合が生じそうですけどね。
敢えてそうまでしてuuidに拘らなければいけない背景があるなら別ですけど。

また、他のシステムと連携するのにUUIDを使用するような場合は主キーにする意味はありますけど、そういった連携が少ないシステムではメタデータ扱いで十分だと思います。
uuidをメタデータ扱いにし、数値型のサロゲートキーを採用する場合のメリットとしては容量とレスポンスですね。

[aoju]

解答ありがとうございました

たしかにサーバー管理の場合は２重管理でいつか不整合が出そうな気もしてきました
今回は初回だけのデータ投入としてSpreadsheetで管理し、それ以降はサーバーで管理する想定なので初回データだけはSpreadsheetのapp scriptでuuid v4生成関数を作って入れ込むようにしたいと思います

> また、他のシステムと連携するのにUUIDを使用するような場合は主キーにする意味はありますけど、そういった連携が少ないシステムではメタデータ扱いで十分だと思います。

今後firestoreや他nosqlへのデータ転用・レプリケーションを考えていたため、uuidを主キーにすると都合が良かったというのもありました
おっしゃるとおりそのような連携が少ない場合はメタデータ扱いで十分そうですね

ありがとうございました！