asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Datastoreのデータモデル設計のふりかえり, パート2

はじめに


パート1を読んでいない人は、この節を読んで下さい。

個人的に趣味で、Goole App Engine/Java(実際はScalaを使用)を使い始めて一年ぐらいになります。そこで、このシリーズでは、Datastoreのこれまでに設計したデータモデルについて少しふりかえりながら、
-設計上の失敗点
-データモデルのパターン(デザインパターンと言う意味ではない)
-データモデルの進化のパターン(プロパティの追加や削除など)
などについて考えていきたいと思っています。

基本的には、JDO使用で、一部、Objectifyを使ってます。

事例として作ってるWebサイトはGoodsHomeというもので、もともとは、新刊の定期自動チェックのために作ってました。今は、モノ(商品)を中心としてファンやユーザーがつながれるようなソーシャルなサイトにしようと思ってます。

現状、Kind数(クラス数)は、47でした。この中の単純なモデルから順に見ていきたいと思います。

考察


パート2では、WishTagというデータモデルを事例にして考えていきたいと思います。このモデルは、ある商品を欲しいと思ったユーザー数(正確には思った回数)を表すものです。facebookの「イイネ!」ボタンと同じような機能です。ユーザーが「欲しい!」ボタンをクリックすると、カウントが一つ増えます。

kind_WishTag.png

プライマリキーは、asin(amazonの商品ID)です。countはクリック数を表します。ちなみに、現状、1,800程度のエンティティがあります。

このモデルに対する操作は、三つです。
(a) エンティティの作成
(b) countの更新
(c) countの読み取り

特徴は以下です。
(1) 他のエンティティへの関係を持たない(Key経由でも持たない)。
(2) プロパティは、更新/読み取りされる。
(3) 各エンティティは、(特に理由がなければ設計上は)削除されない。
(4) トランザクションは必要である。

下記の図は、上記のようなモデルをより一般的に表したものです。
kind_patten2.png

設計上の悩み



設計上の悩みは、どのユーザー(ユーザー登録している者としていない者)がいつクリックしたのかを示す情報がないことです。つまりこのような情報を保存するような仕様への変更が出た時、データモデルをどう変更するのか? を考える必要があります。新たなKindを定義することなく、単にプロパティを追加するような変更では対応できないと考えます。


パート3に続く。


付録:データモデルのパターン


パート1で特定したデータモデルのパターン
kind_patten1.png

パート2で特定したデータモデルのパターン
kind_patten2.png
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/106-b029fa43
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。