GASのバッチ、ここ一週間ずっと既存のコードのリファクタリング・置き換えだったんだけど、やっと新規のコードを書ける体制に入った。最初から環境整えておけばよかったなーとちょっと後悔。
Cloud Datastoreのデータモデリングで親子関係が普遍なものならparent keyが上手く使えるんだけど、それが時系列で変化するデータをどう表現したものかに悩んでいた昨今。
「あまり正規化しないほうが良い」みたいな話もあって物凄く悩んだものの、結局はリレーショナルテーブル的なkindを設ける方向に落ち着く。
プログラム的に力技で整合性を保つような設計は大抵運用で崩壊するので、多少冗長であってもデータの持ち方からして整合性が取れるような形の方が長期的には望ましいという経験からの判断である。
実用上はバックエンドのプログラムで隠蔽して直感的に問い合わせられるようにしようと思ってるんだけど、コストによっては二次的に集計した値をentityとして持つべきなのかもなーと考え中。
しかし、Cloud Datastoreのparent keyは上手くハマると便利なんだけど、こいつがあるせいで構造の組み換えがしにくくてNoSQLの柔軟さが損なわれてる面もある気がして悩ましい。
