同期処理における「主キー」のコントロール

同期において「主キー」を正しくコントロールするのは非常に大切で難しい課題です。

従来型の増分シリアル値を利用した主キーで、あるデータベースには1から10の番号が付けられたレコードがあり、別のデータベースには1から50のレコードがあるとします。前者のデータベースで新規レコードを作成すると、順番通りに次の番号（11）が割り当てられます。しかしこのレコードを後者のデータベースに書き込もうとすると、書き込み先にはすでに11のレコードが存在するため、いわゆるキーの「競合」が発生してしまいます。この問題を解決するには、いくつかの方法があります。

同期における主キーの競合の回避の方法論

様々な方法がありますが、主に以下の4つの方法があります。MirrorSyncはいずれの方法もサポートしています。

主キーにUUID（Universally Unique Identifier）を採用する
- 例：「D2EF9F69-5DEA-4FE3-9095-162C77F76FBF」のような36文字の長い文字列
  - UUIDの特徴：統計的に見て値が重複する可能性を排除できるランダムな値です。同期のフレームワークの多くがUUIDによる主キーの管理を採用しており、MirrorSyncも同様にサポートしています。
    - 利点：重複する可能性が非常に低く、データベースからあるデータベースへ、IDの競合を心配することなく安全にレコードを書き込むことができる
    - 欠点：長い文字列のため可読性がやや低い
従来型のシリアル番号と何らかの条件を組み合わせた主キーを採用
- 例：ユーザ1が作成したレコードの主キーは「1.1」、「1.2」、「1.3」／ユーザ2が作成したレコードの主キーは「2.1」、「2.2」、「2.3」など
  - 特徴：ユーザのイニシャルやファイルIDのなどを組み合わせて主キーを作成することで競合の発生を回避します。MirrorSyncでは、後述の方法でこの問題を管理することができます。
    - 利点：この方法で作成された主キーは、UUIDよりも短くて読みやすい。
    - 欠点：各ユーザに固有の識別子を割り当てるための確実な管理方法を検討する必要がある。
各ユーザに特定の番号帯を割り当てて主キーを生成する
- 例：ユーザ1は1〜10,000、ユーザ2は10,001〜20,000
  - ユーザごとに予め番号隊を割り当てることで、同期時の主キーの競合を回避します。
    - 利点：テキスト形式ではなく数値タイプの値を使用できる。
    - 欠点：ユーザのレコードが予定されていた数を超えた場合に競合が発生する場合がある。
主キーを他方のデータベースに書き込まない
- 例：11番のレコードを1つめのデータベースから2つめのデータベースに書き込むときに、11の主キーを書き込むのではなく、51の主キー（2つめのデータベースで、次の順番にあたる番号）を書き込みます。
  - 解説：単一のデータベースで主キーを発行する時の方法と同様で、MirrorSyncの特徴的な同期方法です。この方法では、MirrorSyncの内部テーブルにおいて、同期しているすべてのデータベースの主キーを管理して調整します。そのため11番のレコードが後から更新されると、MirrorSyncは2つめのデータベースの51番のレコードを変更することを認識します。MirrorSyncは、あるデータベースから別のデータベースに書き込むときに、外部キーも書き直します。そのため、1つめのデータベースで「11」を含む外部キーは、2つめのデータベースでは「51」に書き直されます。
  - 利点：できる限り短い、純粋な数値の主キーにできる上、競合の可能性がない。
  - 欠点：MirrorSyncの内部テーブルを利用しているため、既に同期している別々のデータベースをMirrorSync以外の同期フレームワークに移行するのが困難になる場合があります。

MirrorSyncにおける主キーの管理

MirrorSyncでは主キーの管理方法を以下の2種類から選択できます。

開発者が管理
- 前項の1、2、3はMirrorSyncでは「開発者が管理する」方法と考えられます。MirrorSyncは同期されるデータベース間で主キーを変更せずに書き込むからです。何らかのスキームを採用して別のデータベースの別のレコードに同じ主キーがまったく使われないようにするのは、開発者の責任です。同じような考え方でさまざまなバリエーションがありますが（たとえば一方のデータベースは奇数、もう一方は偶数を使うなど）、MirrorSyncから見ればすべて同じことです。開発者が管理するキーには、「データ入力時の値変更の禁止」オプションを設定することはできません。MirrorSyncがこのフィールドに書き込む必要があるからです（レコードがもともと作成されたデバイスに一致させるためです）。
MirrorSyncが管理
- 前項の4つめは、「MirrorSyncが管理する」方法と考えられます。開発者は、異なるデータベース間で主キーがユニークであることに責任を負いません。MirrorSyncが代わりに責任を持ちます。MirrorSyncが管理するキーには「データ入力時の値変更の禁止」のオプションを有効にできます。MirrorSyncはこのフィールドから読み出すだけで、書き込みはしないからです。

MirrorSyncの設定画面ではどの主キーの管理方法を選択するべきですか？

同期するデータベースで、シンプルな自動で増分するシリアル番号のフィールドを1つだけ主キーとして使っている：

「MirrorSyncが管理する」を推奨します

上記に当てはまらない全ての場合：

その他の場合は（UUID、派生キー、ユーザの入力に基づくキーなど）、開発者が管理するキーを使いましょう。ただし、送り状番号、業務番号、請求書番号など「ユーザフレンドリー」な番号を使う必要がある場合は、決定を下す前に、この後のFAQでユーザフレンドリーなシリアル番号に関する解説をお読みください。

主キーについての注意事項

意味のあるデータを主キーとして使用しない

主キーには意味のあるデータを「使わない」ことを強く推奨します。（MirrorSyncに限らず、データモデリング全般的に）
主キーは誰かの名前、イニシャル、社会保障番号、勤務地、企業名、ユーザ名などに基づくものにすべきではありません。
どうしても主キーに意味のある値をを使用する必要がある時は、必ず「開発者が管理する」主キーを選択してください。開発者が管理するキーを使うときは、複数のデバイス上の同一のテーブルには同じ主キーが決して作成されないように、あなたが責任を持たなくてはなりません。

同期における主キーの値タイプ別の特徴

これから同期構成を行うデータベースを用意する際、以下の特徴を考慮して設計することをおすすめします。

主キーにシリアル値を使用する（推奨）

シリアル番号は比較的データが小さいため、バンド幅をとらず高速に同期できます。

主キーにUUIDを使用する

UUIDは、MirrorSyncを使わずに手動で同期したりインポートしたりする場合
例えばUUIDだけをサポートしている他の同期ツールに乗り換える可能性がある場合、この方法をあらかじめ選択しておくと都合が良いことがあります。
UUIDを主キーとして使用する場合、主キーとしてUUIDを使用している場合のFileMakerフィールド定義の入力値の制限の設定も参考にしてください。

主キータイプとMirrorSync構成時のよくある設定間違い

❌既に主キーとしてシリアル番号を使っていて、同期用に新たなUUIDのフィールドを作り、それを主キーとしてMirrorSyncで使用する：MirrorSyncは、外部キーの数字を振り直すことはしません。そのため、レコードをサーバと同期するときに、誤った子レコードが誤った親レコードを参照する不具合が発生します。
❌主キーとして計算値を使用している場合に「MirrorSyncが管理」を選択して同期を構成する：たとえば複数のフィールドを組み合わせたり接頭辞を付加したりしている場合は、MirrorSyncの構成で「開発者が管理する」を選択してください。この場合、すべてのデバイスにわたって主キーがユニークになるように、開発者が責任を持つことになります。
注：シリアル番号のような単一のテキストフィールド、数値フィールドの場合は、必ず「MirrorSyncが管理する」を使用します。

原文：What is the difference between 'MirrorSync-managed' and 'Developer-managed' primary keys? Do I need to change how I do my primary keys? Which one should I pick?

このセクションの記事

「MirrorSyncが管理している」主キーと「開発者が管理している」主キーの違いは何ですか？　自分の主キーの動作を変更する必要はありますか？　どちらを選ぶべきでしょうか？