NSAS平野さん

仕様上100万件は可能でも、大量データに向いた製品は他にもたくさんあるので、用途に見合った技術を選定する必要がありますね。OracleやGoogleさんと連携するのは良い解決策だと思います。^^

Accessには、私も苦い思い出が多いです。^^;

結局、Accessは業務で真面目に使うのは厳しいツールではありましたが、AccessでDB/SQLやVBの基礎、そしてホストコンピュータのように堅牢ではない環境^^;を学ばせてもらったので、よかったと思います。

キンスキ松井さん
情報ありがとうございます。なるほど！「100万件が一つの基準」ですか。ヘルプも参考になりました。

正直な感想としては、100万件が大丈夫であれば、ほとんどの場合問題ないです。逆に「100万件以内ならOK！」が社内で独り歩きしてバンバン依頼がきそう^^;。あと快適かどうかは、主観的な部分もあるので利用者から「快適じゃないじゃないか！」と言われたら「私は快適だと思いますけど。。。」とならないかがちょっと心配^^;。その場合はどうしようかな。「Excelよりは快適ですよね。」で返そうかな。^-^;

＞ソート条件に適用するフィールドの種類による処理時間の違い
面白いです！フィールド種類によってソート時間が変わるんですね。文字列や数値は件数によって差はないので内部で事前にインデックス化されてるとして、ラジオボタンやドロップダウンはソート時にレコード１件あたりにつき何らかの変換や検証が入るのかな。。。内部的にはリスト順を数値でもってて、ソートする為には一旦文字列変換しないといけないからかな。。。だとしてもクラウド上で可能な所は並列処理されてるだろうから、並列処理できない何か事情があるのかな。。。表示件数は同じ100件なのでクライアント負荷はあまり関係ない気がするし。。。とか色々想像してしまいます。

＞大前提としてkintoneは他のデータベースに比べると、大量データの扱いには向かない製品です。
個人的には、性能面では、一般通常利用レベルとしては、ある程度大量データの扱いも十分な性能であると認識を改めました。^^

今回の情報、説明時に活用させていただきます！
ありがとうございました。

tarimo様
ご返信ありがとうございます。

そうですね。kintoneのデータ容量単価が他ストレージと比べて高価なのは事実ですから、まずそれを利用者と共同認識を持って、「貯めておく理由と普段の使い方」「明細データか集計データか」検討すべきですね。改めてそう思いました。

検討するポイントとしては、大量データの場合、検索速度や使い勝手などもありますが、実物を見ない段階で利用者にはイメージしにくいという側面もあります。やっぱり「費用対効果」お金の話が一番ピンときますね。^^;

ありがとうございました。
今後ともよろしくお願いします。

松田様
ご返信ありがとうございます。

＞「kintoneに入れて何をするか？」ではないかと思います。
そうですね。単に「多い少ない」の問題ではなく、大事なのは「価値があるかないか」との兼ね合いですね。たとえ数万件でも価値があるなら検討すべきですし、極論、価値がないなら１件でももったいない^^;。おっしゃる通りです。

依頼側は往々にしてすべてのデータを入れたいという心理が働くので、開発側は反射的に否定する方向で返答してしまいがちですが、反省して「情報の価値」についていっしょに考えてみることにします。

本音としては、余裕があればデータはあるに越したことはないのですが。。。グレープシティさんのkrewDashboardのグラフ機能でドリルダウンを使ってたりすると、やっぱり明細までドリルダウンしたいなーって思ってしまいます^^;。そこはバランスをみて、ある程度以降は「つづきはこちら⇒」みたいに基幹イントラにつなごうかなと思ってます。

＞アプリのデータ容量節約のために、変更履歴の記録をオフにしておくというノウハウもあります。
そうですね。それも大事ですね。数千件程度ですが、すでに毎日洗い替えしているアプリのデータがありましたので、早速先ほど
「レコードの変更履歴を記録する」
のチェックを外しました！

適切なアドバイスありがとうございました。大変参考になりました。
今後ともよろしくお願いします。