現在一枚のある記録をする様式の紙があります。
結構一枚の中に記載する項目が多く、、、これだけの情報を一つのアプリにぶち込むものなのか？と思ったりしています。
元々自分でDBなどを作ってやっているときはリレーションとかを考えてしまって、マスターとか、それぞれの分野的な感じで分けつつ、ID紐づけとかをしていたのですが、、、
Kintoneでアプリを切り替えながらするっていうのもちょっと違うのかな～とか思ったりもして、、、
ちなみに、項目ごとにボタンを押して表示非表示させることで、スクロールさせることが少ない仕様にしたとします（その機能はできてます）。
その後それらのデータをまた印刷用に整形したりしつつ、印刷できるような部分まで持って行くつもりではあるのですが、、、
もちろん、さすがにこれはルックアップとかっていう部分に関してはそれはそれで作成したりしつつとは考えています。
みなさんとしては、最大これくらいまでのとかあるよ～っていうのを参考までに教えていただけますか？
Kintoneでもリレーションをすごく考えてますか？
Fetherion さん
参考になるかわからないですが、1つのアプリに全部入れてしまうとどうしても項目数は多くなるので、ルックアップとか関連レコード一覧とかのフィールドを使い、関係性を考慮してマスタとしてのアプリを作成するのは珍しくはないと思います。
自分のところにはフィールド数が多いアプリはありませんでしたが、過去の投稿 見てると、快適に動作させる場合は 100個ぐらい という話をしている投稿もありました。
ただどうしても、お使いの PCの性能やネットワークにも依存しますし、公式の記述 だとレコード数も依存しそうな気がします。
関係性などを含め、使用しながら使い方を覚えてアプリを育てていくという感じかなと思います。
コメントありがとうございます！
快適動作で１００個ぐらいという部分参考になります。まぁ、、、そこまでは無いんですがｗｗ
Kintone自体がDB向けアプリだとは思っているので、やはりそうはいってもリレーションになってきそうな部分は当然たくさんあるので、いろいろ設計等を考えながら見ていこうと思います。
Yoshidaです。
>結構一枚の中に記載する項目が多く、、、これだけの情報を一つのアプリにぶち込むものなのか？
フィールドが多くなることはありますね。
要件定義の段階で少なく出来ると良いのですが、システムリプレイス案件だと以前の物をそのまま
とかやってると200~300フィールドになったりもします。
>元々自分でDBなどを作ってやっているときはリレーションとかを考えてしまって、
kintoneはDBなので、普通にマスタとかトランザクションとかDB設計します。それで良いと思いますね。
ただ、RDBのようにリレーションを貼るのはしぶいさんも言っている通り、ルックアップと関連レコード一覧
になるので、マスターを変更した時に紐付くデータを変更するのは自前でやることになります。
ここは考え方なのでそう言うDBだと思ってます。
>Kintoneでもリレーションをすごく考えてますか？
個人的にリレーションは考えます。でもあまり細かくマスタにするのはしませんね。
ケースバイケースだと思います。
要件定義の段階でマスタに切り出す程でも無いときは、マスタアプリにしないで最初は
ドロップダウンにしておいて、増えたらマスタに切り出しましょう。とかやってます。
kintoneにおけるDB設計の話し？になるのかな。この辺りはとても興味があるので、
このスレッドでも良いですけど、何処かで他の方のご意見もいただきたいですね。
Yoshidaさん
返信等アクションが遅くなり申し訳ありません。
フィールドはやはりそうなるものはなっていくものであるんですね。
確かに、細かく考えることはありますが、これを細かくしてこのKintoneでの運用としてはどうか？ってなったりはしているので、そのマスタとして選択する項目数や決まりなどを考えて、普通にドロップダウンしておく方が楽だったりはしますね。
Kintoneカフェとかだとこういう話は盛り上がるんですかね？ｗｗ
自分的にプログラミング自体の話も周りにできる人がいなくて、会社はRICOHさんが来るけど、当然営業とかだとそういう話はしても通じないから。。。
Kintoneの作り方は当然だけど、裏側の考え方とかもいろいろ意見聞きたいですね＾＾