トップ > ソフトウェア技術 > コレはちょっとおいらと考え方が違うかな

コレはちょっとおいらと考え方が違うかな

ソフトウェア技術

http://d.hatena.ne.jp/nowokay/20100106#1262801414

例としてGAEがでてるけど、GAE以外のKEY-VALUEストレージならばまぁわからなくもない。

ただGAEはバッチが絶望的なのでガッチガチに作る場合、エンティティのバージョンごとにクラスを用意して新しいバージョンがあるならそのデータの加工をまずするといった使い方が必要になる。

バージョン1，２，３のエンティティがあったとして、格納されるデータがバージョン２だったらバージョン3へアップデートするためのメソッドをバージョン3のエンティティクラスにメソッドを用意し、それを実行、バージョン1だったらバージョン2、バージョン3と順番にデータをアップデートするメソッドを実行といった「いわばLAZYなバッチ」が必要になってくるはず。

それならば最初から全て文字列でデータは保持、データはわりといいように取得、アプリはある程度の融通を持たせつつ、データの取得がしやすい形を作る、といった仕組みのほうが個人的にはいいのかなと思っている。

これは過去にも書いてるね。
http://d.hatena.ne.jp/shin/20091201/p1


運用していると数値型だったのが文字列型になったりとかはよくあること。今まではバッチを流せばよかったがこれがなかなかできない。

そもそもGAEのBigTableは型をある程度持っているはずなんでどーなんだろうと。完全にスキーマレスといっていいのかどうか。


ここからコアな話になる。


あとエンティティクラスを使うときにはそれが直接データアクセスに使われてはいけないというのもBigTableの特徴だろう。

たとえば掲示板のシステムの場合、普通にRDBで作ればスレッドのタイトル等を保持する親用に1つ、レス用で1つのテーブルを用意して連結して使うことになると思う。データアクセス層でも、フロントエンドであっても（こちらは加工されたりするがデータをそのまま持ってくるという意味で同じものと考えてよい）。

おいらがテストで作ったGAE用の場合クライアントはGWTだが（考え方はHTML生成するサーバーサイドであっても同じ）、このサービス層ではRDBと同じDTO単位でのアクセスをする。

ただし、実際にそれを登録するデータアクセス層では、構造を加味した上でDTOをまとめてひとつのDataStoreのエンティティにしたり分解したりといったことをしつつ登録する。

したがってエンティティクラスをそのままマッピングしてそれをフロントエンドまで流していくという使い方はGAEと相性が悪い。なんせ、上記のエンティティのプロパティは動的に追加されることになるからだ。

たとえば1スレッド100レスが可能な掲示板として（実際においらのテストではこれ）、このエンティティのプロパティは最初のスレッド新規作成時の書き込みはR1、次の書き込みはR2、といったように動的に増えるような形にする。しかしこのままではやりとりがしにくいのでDTOではRDBのような構成をとる。レスをListで保持して親子関係を持つように変換したりとか。BigTabel見てると排他制御周り等に使いにくさが出るので、このへんは結局熟練した開発者が作りこまないといけなくて、エンティティにクラスを単純に当てはめるO/Rマッピング（というかデータマッパーパターンか）はそこが作りにくいはず。

RDBの便利さの延長での開発はBigTableやKey-Valueストアにはあわないかなと。まだ試行錯誤中ですが。


もちろんアプリのレベルで利用するDTOでは型がついているほうが複雑なGUI構築上でも便利なのは間違いない。BigTableやKey-Valueストアが普及すればDTO＝Entityそのまま使うってのは減るかな？