2008-04-17-01-【Scrooge】データ構造 - 5
>> Site top >> weblog >> 月別アーカイブ >> 2008年04月のlog >> 2008-04-17-01-【Scrooge】データ構造 - 5
最終更新日付：2014/01/02 00:00:00
【Scrooge】データ構造 - 5
2008 年 04 月 17 日
簡単に前回のおさらいをしよう。まず、Scrooge のデータ表現では３つのデータベースを使用する。
- ShopDB : 店舗名データベース
- ItemDB : 商品名データベース
- PriceDB : 価格情報データベース
PriceDB は特定の店舗×商品の組み合わせに関して価格情報を保持するが、店舗や商品そのものの情報については ShopDB と ItemDB 上のレコードの UniqueID への参照を保持する。PriceDB の各レコードに格納される PriceInfo は以下のようになる。
struct PriceInfo {
UniqueID shopID;
UniqueID itemID;
UInt32 price;
struct DiscountInfo discount;
};
DiscountInfo は割引イベントの情報で、現時点ではブラックボックスだ。で、PriceDB の各レコードとして存在する PriceInfo 構造体も、レコードとしての UniqueID を持つ、というところで前回は終わったのだった。
さて、画面に表示しているのが店舗ビューであれ商品ビューであれ、対応する価格情報が存在しない（つまり未入力の）組み合わせも全て画面上に表示するのであれば、画面に表示するレコードの数は（スクロールの要否はさておき）ShopDB か ItemDB のレコード数に等しくなるはずだ。つまり、店舗ビューであれば画面には商品が全て表示されるし、商品ビューであれば店舗が全て表示されるのである。
まずは以前の「どちらでも似たようなもの」と書いた意味を説明しなければならないので、単純愚直な実装を想定しよう。必要なのは、一覧すべきデータベースのレコードを参照する UniqueID と PriceDB のレコードを参照する UniqueID をペアにするデータ構造だ。
struct PriceMap {
UniqueID keyID;
UniqueID priceInfoID;
この時点でデザインとして書くにはやや気恥ずかしいほど愚直だが、説明のためなので我慢してほしい。keyID は ShopDB または ItemDB いずれかのレコードの参照で、どちらなのかはアプリケーションが知っている。priceInfoID は PriceDB のレコードへの参照だ。
なぜこんなものが（説明のためとはいえ）必要かというと、価格情報が未入力であるような組み合わせでも画面に表示する以上、店舗（または商品）の一覧を軸にしなければならず、それらを対象として選択中の情報とマッチする価格情報へのマッピングをしなければならないからだ。しかし、このような情報があれば priceInfoID を０にすることで「未入力である」ことを表現できる。だから PriceDB は ShopDB と ItemDB の直積分のレコードを常に保持する必要はないのである。
混乱しただろうか？ だとすればそれはかなりいい加減な書き方をしている陰郎の説明に問題があるので気にしないでほしい。さて、こんな愚直なデザインをそのまま実装するのも恥ずかしいので、次回以降、「もう少し工夫」することを考えるとしよう。実のところ、ちゃんと作れば先の PriceMap のようなものをダイナミックヒープ上に作成する必要などないのだ．．．というところで続きは次回以降。
コメント
このページのタグ
Page tag : Palm
Copyright(C) 2005-2018 project-enigma.
Generated by CL-PREFAB.
