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

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

あの商品,駅前Ａ,100
あの商品,近所１,105
あの商品,駅前Ｂ,
あの商品,隣町Ｘ,135
あの商品,近所２,140
その商品,駅前Ａ,240
その商品,近所１,200
その商品,駅前Ｂ,225
その商品,隣町Ｘ,
その商品,近所２,240

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

1,あの商品
2,その商品
─────
1,駅前Ａ
2,近所１
3,駅前Ｂ
4,隣町Ｘ
5,近所２
─────
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

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

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

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

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

Page tag : Palm