2008-04-05-01-【Scrooge】データ構造 - 1 - project-enigma

2008-04-05-01-【Scrooge】データ構造 - 1

>> Site top >> weblog >> 月別アーカイブ >> 2008年04月のlog >> 2008-04-05-01-【Scrooge】データ構造 - 1

最終更新日付:2013/12/31 07:37:07


【Scrooge】データ構造 - 1

2008 年 04 月 05 日

そろそろ Scrooge のデータ構造を考えてみようと思う。例によって単純愚直なデザインから始めて少しずつイジっていく。必ずしも自分の思考の道筋をトレースするというわけでもない。

ひとまずのところ、店舗の集合と商品の集合があり、両者の直積をとってそれぞれに価格の設定があると考えることになるから、もっとも愚直なのはそれがそのままのイメージでレコードになるというものだ。

あの商品,駅前A,100
あの商品,近所1,105
あの商品,駅前B,
あの商品,隣町X,135
あの商品,近所2,140
その商品,駅前A,240
その商品,近所1,200
その商品,駅前B,225
その商品,隣町X,
その商品,近所2,240

当然ながら、これではあまりにも芸がない。そもそも、同じ名前の商品や店舗は名前だけでなく実際にも同じものを指すわけだから、名前でコピーするのは良くない。結局、良くある RDB 的な発想を取ることになる。

1,あの商品
2,その商品
─────
1,駅前A
2,近所1
3,駅前B
4,隣町X
5,近所2
─────
1,1,100
1,2,105
1,3,
1,4,135
1,5,140
2,1,240
2,2,200
2,3,225
2,4,
2,5,240

普通に考えれば、これらは別々のデータベースに格納することになるだろう。そして、例のポップアップリストに対する要素の追加・編集・削除というのは最初の2つに対して行うことになるわけだ。

割引きイベントの設定についてはなにも触れていないが、これは価格情報に続いて記録されることになるだろう。ひとまずは面倒なので、今回は書かない。

最初に、商品と価格の直積(要するに全ての組み合わせ)がデータの全体になると書いたが、「その店舗でその商品は売っていない」という場合でもレコードは存在するべきだろうか。それとも実在する組み合わせのみがレコードとして存在するべきだろうか。

結論はほとんど見えているが、続きは明日以降。

 

コメント

このページにコメントする

 

このページのタグ

Page tag : Palm

 

 


Copyright(C) 2005-2017 project-enigma.
Generated by CL-PREFAB.