FileMaker の「レコード ID」の取り扱いは難しい

「レコード ID」の公式リファレンスの定義

「レコード ID」とは何か。「レコード ID」を取得する関数であるGet (レコード ID)について、公式リファレンスには以下のような記載があります。

返されたこの番号は、レコードの作成時に FileMaker Pro によって生成された 10 進法の値 (整数) です。この値が変更されることはありません。

すなわち「主キー」である

上記の定義より、「レコード ID」はいわゆる「主キー」であることが分かります。FileMaker では「主キー」が存在しなくてもデータベースを運用できます（ように見える）が、主キーに相当する部分が裏側では用意されていることになります¹。

しかし「レコード ID」の取り扱いは難しい

しかしながら、この「レコード ID」はなかなかにその取り扱いが難しいです。その理由は、「レコード ID」はフィールドとして存在していないからです。

このため、「レコード ID」は範囲を指定して検索することができません²。また、リレーションシップに組み込むこともできません。

ではどう扱えばいいか

となるとこの「レコード ID」はどう利用すればよいのでしょうか。

だいたい感づいているとは思いますが、そう、「レコード ID」がそのまま入るフィールドを作ればよいのです。そしてそれをテーブルの主キーにしてしまえばいいでしょう。「レコード ID」は未来永劫ユニークで、かつ NOT NULL であることが保証されていて、さらに「意味を持たない」「数値」を取るため、主キーとしてはもってこいです。

予め用意されていることが確定しているので、「サロゲートキーの要・不要議論」などに振り回されること無く「利用してやれ」の一択でしょう。

補足

1. テーブルの主キーを誤って設定してしまった場合（当初設定した主キーが、主キーの要件を満たさなくなりそうな場合）にも、「レコード ID」の値が入るフィールドを作ってあげればそこで主キーの要件が満たされ、助かることでしょう³。

2. 同種の値に「レコード編集回数」というのもあり、こちらの値もフィールドとして外に出してあげてよいかと思います⁴。

1. そうでないとレコードの一意性が保証されなくなってしまいます ↩

2. 一つ一つ値をを決め打ちして検索することはできる ↩

3. 「最後の砦」になり得る ↩

4. 使いどころが難しいですが ↩