kintoneにおける採番について

はじめに

kintoneはデータストアであるため複数(ときには大量)のデータを格納する。
このとき各レコードにおいてレコードを表すキーになる項目を主キーという。
主キーには、文字列や数値を使う事が多い。
本エントリーでは、採番について私が今まで経験した設計上の重要な点や気付いた点を記す。

主キーを採番する上でのセオリー

まず私の経験上、以下のルールを選択した方が良い。

• kintoneのレコード番号は、主キーにはなるべく使わない方が良い。
  理由
  アプリを入れ直す必要が発生した場合に、レコード番号が前のアプリと同じになる保証が無いため、アプリ間の紐付けが壊れてしまう可能性が高い。

• 採番は数値の連番が一番良い。
  理由

  • ソートもし易いし、その際のアルゴリズムも単純である。

  • 例えば文字列と0パディングした数字を組み合わせた場合、アプリを作り直してデータをエクスポート・インポートしたときに必ずしも古いアプリにおけるレコードの順番でインポートされるとは限らないため、最新の番号を採番するときソートのアルゴリズムのとの兼ね合いで、場合によってはデータ移行の手間が増えてしまう可能性がある。それに比べると数値の連番は運用も含めて扱いが楽である。

採番処理の奥深さについて

採番処理は作ってみると意外に奥が深い事に気付く。
弊社でもCybozu社が公開している自動採番プラグインを参考に、枝番の発行や外部アプリにて最新の番号を管理する採番処理を実装したが、なかなか大変だった。
採番というと単純に最新の番号に次の番号を付与して保存すれば良いように思い、簡単に思ってしまう。(実際私は最初プラグイン化はかなり楽な作業だろうと思った。) 実際SIの現場で請負の案件であればそれほど複雑な実装をする必要はないかもしれない。
しかしプラグインとして動かそうとすると意外に複雑な要件が発生するのに気付く。
以下にそれを列挙する。

• まず新しい別のアプリにデータを移行する必要が発生した場合に、新しいアプリで最新の採番番号をどう取得するかという問題が発生する。
  例えば先に上げた自動採番プラグインでは、TEXTA-001のような採番を行う事も出来るが、アプリの移行に際し「TEXTA」の部分の固定文字列が変更された場合、ソートして最新の採番番号を正しくとれるのかはプラグインの実装に依存してしまう。
  場合によってはプラグインのソートのアルゴリズムを確認して、採番済みの番号を参照先も合わせて変更するなどの処理が必要になる可能性がある。

• レコード件数が多すぎて全件検索するには無理があり、kintoneのソートアルゴリズムにてソートすると意図しない順番になる可能性や、最新で登録したレコードから採番番号を取得するようなアルゴリズムを採用している場合、先の項目と同様に別アプリにデータを移行した際、必ずしもアプリ移行後に最新のレコードに最新の番号が入っているとは限らないことがあり得る。

上のような事について考慮が漏れると思わぬ動作を招く可能性がある。
よって採番は、扱いやすさで考えると数値を使うのが、ソートもし易いため一番良い。または最新の番号を管理するアプリを別に作り常にそこを参照するのも次善策である。逆にそれ以外は、アプリの移行などの運用も含めた考慮が必要になる。

以上のように採番を行う場合は、最新の番号の取得やデータのエクスポート・インポートも含めた運用を考慮する必要があるため、意外に奥が深く注意が必要である。
kintoneアプリを作る際は上記を留意する必要がある。