勝手にkintone SIGNPOST解説 STEP.3 3-27「親子アプリ」

アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ!

本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。

STEP.3 3-27「親子アプリ」

kintoneはとても手軽にデータベースを作ることができるので、それまでシステムについて学習をしていない人でも使うことができます。

しかし、kintoneはデータベースです。データベースでもっとも重要なのは設計で、そこをある程度勉強しておかないとkintoneを使いこなすことはできません。

このパターンに書かれていることはまさにこの部分で、ある項目を考えたとき、それをどのフィールドタイプにするか、そもそも別アプリにしたほうがいいのか、そこを適切に設計する必要があります。

アールスリーで観測している範囲で非常に多いケースが、テーブルと関連レコードの使い分けです。

データの親子関係というのは頻出します。たとえば、注文と注文明細みたいなものです。kintoneで考えるとき、この注文明細をテーブルにするか別アプリにして関連レコードにするかはとても悩ましく、判断に困るところです。

このような場合、多くの方が手軽に使えるテーブルを選択します。ただテーブルにすると後から困るいくつかの制限があります。代表的なものとしては、

  • テーブルのフィールドにはアクセス権が設定できないため、人によってみせるフィールドを制御できない
  • テーブルの各行にもアクセス権を設定できないため、行を見せる見せないを制御できない
  • 集計の対象にできない
  • (基本機能では)行の並べ替えができない

のようなことがあります。これをなんとかしようとgusuku Customineでのカスタマイズを試みる方もいらっしゃるのですが、こういう場合は素直に関連レコードにしてしまったほうがいいケースもあります。

追加・編集時に別アプリを開かないといけないという手間がありますが、そこをgusuku Customineで補助してあげるのも1つの方法です。

最初にテーブルで作っていたとしても、あとから要件が変わってきたときに別アプリにして関連レコードに変えるのも方法としてはあります。変更の手間は大きいですが、必要であればやってください。一番ダメなのは、テーブルがいいか関連レコードがいいかを悩み続けて0-02 素早く繰り返すことができなくなることです。

kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。

Back to Blog

Related Articles

勝手にkintone SIGNPOST解説 STEP.3 3-31「性能への気遣い」

アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ!

勝手にkintone SIGNPOST解説 STEP.3 3-26「担当別アプリ」

アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ!

勝手にkintone SIGNPOST解説 STEP.4 4-36「利用率の把握」

アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ!