DB化
こういう感じじゃないですかね。
① 図のようにひとつの行にあらかじめ日付を並べておき、毎日「今日の列」を探し出してそこにデータを書き出す。
(欠点:目視だと一目瞭然なのに、毎日膨大なデータから「今日の列」を探し出すのがあまり簡潔ではないかなと思いました)
前提としてセルの上限が 500 万です。
行・列、レコード量をどう想定するかわかりませんが、コンピュータにとって実際それほど膨大ではないと感じました。
また、無料の場合(変更がなければ)スクリプトが 5 分しか動作しないと思いますが、そこを気にするのであれば、何年何月何日が何列目なのかは計算で求まるので、毎日「探す」必要はないです。
(js の Date では求める日が何列目か計算が難しく感じられるかもしれませんが、年でスプレッドシートをわけ、シートを月にしたり、1スプレッドシートでも年でシートをわける設計にするなど簡単に列を求められる構成が想定できます)
② 日付の行はあえて空白にしておき、getLastColumnで「記入のある最後の列 + 1」を今日の列とする。データを書き出す際に日付の行に今日の日付を記入。
(欠点:PDFは一度届いたあと「訂正版」が届く場合もあり、その際一度入力された列に上書きしたいのですが、それができず同じ日付の新しい列を作ってしまいます)
こういう場合に appendRowできる点で 1 行目を見出しにする構成が有利です。
追記にする場合、閲覧・分析するロジック側で集約すればいいので(1 行目の日付は内部的にはjs の Date で時刻の情報をメールから持ってこれるので、同じ日はより新しいデータ 1 件のみを取ればいいと想定)追記する構成の場合同じ日付の新たな列があることは問題にしないと思います。
この場合、集計のところで別の計算上の負担が発生する(=計算が別の所に移動するだけな)ので、データ取り込みの際に日付を探す処理を短絡化するためだけに追記にする、のはあまり意味がないと感じます(そもそも前提として日付を探さないといけない、かは前述のとおり再考の余地がありそうですし)。
追記的な処理にするかどうかは、変更されたことを記録することに意味があるかや更新処理にかかる時間を待てるかで判断すると思います。
この処理にそこまでの応答性能は求められてないと思いますし、追記にしてもさほど早くならないので、変更を記録しておきたいか、が肝ではないかなと感じました。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2021/08/25 09:09
2021/08/25 09:47
2021/10/15 03:51