[現在のアプリ構成]
レコード番号フィールドを、IDとしています。
他のアプリでは、そのIDをルックアップ時に使用しております。
[データリストア時の課題]
現状のアプリ構成では、アプリのデータをリストアで復旧する際に、IDを以前の状態に戻すことがkintoneの仕様上、難しい状況です。
※現状のデータリストア方法は、kbackupの定期バックアップという機能です。
[質問]
データリストアを考慮した際、アプリ構成は、レコード番号フィールドを使用せずに、数値フィールド(重複不可)にするのがベストでしょうか。皆さまは、どのような構成にされていますでしょうか。
また、数値フィールド(重複不可)にした場合、別途採番の処理が必要になるかと思います。その際は、プラグインを使用するのが一般的なのか、JSでその処理を用意すべきかも合わせて教えて頂けますと幸いです。
度々浮上する課題ですね。御察しの通り、レコード番号をルックアップや関連レコードのキーに利用するのは、バックアップを含めたデータメンテナンスの際に不利にはたらくことが多いため、極力避けたいところです。そうすると、自ずと重複禁止で事実上必須なフィールドを主キー的なものとしてフィールドを定義するという流れになります。
あとは、その重複禁止で事実上必須なフィールドをどう扱うかですが、選択肢があると思います。
・文字列1行で重複禁止・設定上必須なフィールドとして定義するのも良いかと思います。フィールド設定として重複禁止で必須であれば、レコードの登録時に決まることになるので、問題ないですね。
・数値や文字列1行で自動採番する方法がわかりやすい方法として考えられると思いますが、画面操作でのレコード登録だけを考えればカスタマイズなりプラグインでレコード登録時に採番すると良いと思いますが、CSVやREST APIによるレコード登録に対してどうするかを考慮する必要が出てきます。決まったフォーマットの自動採番があればそれも考慮に入れることになると思いますし、・・・ケースに応じたレコードの登録方法と運用を考慮する必要があるということです。
自分が同様の課題をクリアするとすると、フィールドの設定は重複禁止だけで、画面操作によるレコード登録の時にはその時に採番、CSVやREST APIによって登録されたレコードに対しては、レコード一覧画面で採番されてないフィールドを対象にバルクで採番するロジックを裏で走らせます。
採番フォーマットは要望があればそれをベースにしますが、特にフォーマットを考慮する必要がなければレコード番号ベースで採番するロジックを組むことを考えると思います。これをカスタマイズするのかプラグイン化するのかはその時の要件次第かと思います。
概して、既に想定されている通りかと思いますので、現状の考えをベースに今回のケースに最適化されるので問題ないかと思います。
Yamashitaさん
いつも詳細な回答頂きありがとうございます。
参考にさせて頂きました。