リレーションのキーをいままでは、
hogehogeIDなどのフィールドを作成し、
フィールドタイプ：テキスト、
入力値の自動化（確定時）：シリアル番号、
データー入力時の値変更の禁止、
で運用してきました。
UUIDを使用したいと思います。
特にUUIDにしなければならないこともないのですが、メリットデメリットはありますでしょうか？
デメリットとしては検索や照合に時間が掛かるとか。。。
また、現在のリレーションキーをUUIDに全部置換するにはどうすれば良いでしょうか？
よろしくお願いします。
環境：Filemaker Pro 14 15 advanced
レスありがとうございます。
UUIDはリレーションに使わない場合どういうときに使い道があるのでしょうか？
UUID番号というのがv17からできたのですね。UUID番号もリレーション以外でどう使い道があるのか想像がつきません。
APIでレコードを取得するくらいしか思いつかないです。
UUID番号は、ともにリレーションでの照合計算が低下ではなく向上するのでしょうか？
桁数が多いので速度は低下すると思ってましたが驚きです。
この意味は英数字が混じっているUUIDより、数字だけのUUID番号の方が計算が速いということでしょうか？
UUID番号よりはシリアル番号の方が当然速いでしょうけど。
UUID番号が作られた経緯から察すると、通常のシリアル番号よりUUID番号をリレーションでおすすめしている感もあり、UUIDを使うならUUID番号の方が速いよ（UUIDが遅いからUUID番号ができたとも想像できる）ということでしょうかね。。。
シリアル番号はおっしゃるとおり一目でわかりやすいですね。
今運用の複雑なものを変更するのではなく、新たにアプリを作成する場合も、シリアル番号の方が良いですかね。。。
UUID の使い道としては、独立して動いているシステム間で、レコードの独自性を保つ際には、非常に有功でしょうね。
それ以外にも、通常の運用のデータベースで UUID をりレーションキーとして使っても何ら問題はありませんが、シリアルで十分な事がほとんどでしょう。
UUID番号は数字として扱われます。UUID はテキストとして扱われます。数字のほうが、照合などには、格段に早くなる可能性があります。
シリアル、UUID、UUID番号について理解いたしました、ありがとうございます。
システムの複雑度にもよるかと思いますが、稼働中システムの照合キーを途中で変更するのはリスクが高く、あまり得策ではないと思われます。
>特にUUIDにしなければならないこともないのですが、メリットデメリットはありますでしょうか？
いま特にお困りでないのであれば、現在のシリアル番号でまったく問題はありません。
シリアル番号のメリットは、人が目で見てわかりやすい、という点はあるかと思います。
ただし、データ移行の際にはフィールド定義の「次のシリアル番号」を必ず確認して重複しないようにする、など運用中に配慮しなければならない点はいくつかあります。
一方、UUIDにはその心配はありません。
ただ、パッと見てもその値は記憶に残らないでしょう。以下、UUIDの値の例です。
現在は、v15をご利用のようですのであまり参考になりませんが、上記の２つ目は、v17で追加された関数 Get(UUID 番号)です。結果は数値を返します。
また、パフォーマンスについては、上記関数のヘルプに次のようにあります。
以上、ご参考まで