business model / 'ER' help

[St...@nextgen.net]

Hi I am trying to get my head around a simple practice task, however I 
can't stop thinking about relational models as opposed to document models 
hehe

ok so i have one couchDB database that has to contain 3 stores, each store 
has a product inventory (i.e product name, qty)

I have to be able to:

1. list the total qty of each item (i.e across all stores)
2. list the QTY of a certain item within each store
3. list all items, their qty for a specific store

...I could smash this out in SQL in a few minutes...but cant get my head 
around doing it as documents....eg would I have a document for each store 
containing product attributes(i.e p1, p2 etc)? or a document for each 
product containing store attributes(i.e P > s1-qty, s2-qty, s3-qty)? 

or (and i doubt this be true) would i have separate store docs and product 
docs and somehow link then like I would in a 'real' (:-p) database lol

wasnt sure if these kinds of Q's were asked in here so thought id just 
give it a shot

Re: business model / 'ER' help

[St...@nextgen.net]

this is all hypothetical, but hypothetically it is able to sell one unit 
at a time LoL
thanks for your input(s)
cheers



From:
Ian Hobson <ia...@ianhobson.co.uk>
To:
user@couchdb.apache.org
Date:
01/06/2010 06:45 PM
Subject:
Re: business model / 'ER' help



On 01/06/10 06:19, Steven.Prentice@nextgen.net wrote:
> Excellent proposal Randall, thats an awesome idea, but what if my store
> stock a 200 000 of each item - I think your idea defeats the purpose of
> storing documents a bit, dont you? I have opted to base my documents on
> each product, inside product I have a field called stores which contains
> an array of 3 stores each with a name and item count.. and see if I can
> tackle it that way. Thoughts?
> S
>
>
> 
If your store has 200,000 of an item is stock at any one time, I
rather suspect it does not sell them one at a time!

If you sell the item in packs, then the pack is the stock keeping
unit, and the database should have one record per pack.

For metered products, different answers apply. I rather suspect you will
have to keep running totals.

regards

Ian

Re: business model / 'ER' help

[Ian Hobson <ia...@ianhobson.co.uk>]

On 01/06/10 06:19, Steven.Prentice@nextgen.net wrote:
> Excellent proposal Randall, thats an awesome idea, but what if my store
> stock a 200 000 of each item - I think your idea defeats the purpose of
> storing documents a bit, dont you? I have opted to base my documents on
> each product, inside product I have a field called stores which contains
> an array of 3 stores each with a name and item count.. and see if I can
> tackle it that way. Thoughts?
> S
>
>
>    
If your store has 200,000 of an item is stock at any one time, I
rather suspect it does not sell them one at a time!

If you sell the item in packs, then the pack is the stock keeping
unit, and the database should have one record per pack.

For metered products, different answers apply. I rather suspect you will
have to keep running totals.

regards

Ian

Re: business model / 'ER' help

[St...@nextgen.net]

Excellent proposal Randall, thats an awesome idea, but what if my store 
stock a 200 000 of each item - I think your idea defeats the purpose of 
storing documents a bit, dont you? I have opted to base my documents on 
each product, inside product I have a field called stores which contains 
an array of 3 stores each with a name and item count.. and see if I can 
tackle it that way. Thoughts?
S





From:
Randall Leeds <ra...@gmail.com>
To:
user@couchdb.apache.org
Date:
01/06/2010 01:48 PM
Subject:
Re: business model / 'ER' help



The easiest thing in my mind would be to have a document for each
inventory item that contains its name and the store where it's in
stock.
This is actually kinda nice because it lets you track individual
instances of each item, like if you wanted to order the item to be
sent from one store to another you could modify the store property.

I think you can get away with only two map functions.
Make one map that emits a key like {[item, store]: item_id}. Call it
"items_by_name".
Another map emits keys like {[store, item]: item_id}. Call it 
"items_by_store".
Then all three of your questions are simple summation ({"reduce":
"_count"}) reductions.

1. _design/inventory/_view/items_by_name?group=true&group_level=1
2. 
_design/inventory/_view/items_by_name?group=true&group_level=2&startkey="[item_name]"&endkey="[item_name,
{}]"
3. 
_design/inventory/_view/items_by_store?group=true&group_level=2&startkey="[store_name]"&endkey="[store_name,
{}]"

I think this would work for you. You might need to url encode those keys.
The startkey and endkey parameters are chosen based on the collation
specification[1].

Happy map(-reduc)ing!
-Randall

[1] 
http://wiki.apache.org/couchdb/View_collation?action=show&redirect=ViewCollation#Collation_Specification


On Mon, May 31, 2010 at 20:14,  <St...@nextgen.net> wrote:
> Hi I am trying to get my head around a simple practice task, however I
> can't stop thinking about relational models as opposed to document 
models
> hehe
>
> ok so i have one couchDB database that has to contain 3 stores, each 
store
> has a product inventory (i.e product name, qty)
>
> I have to be able to:
>
> 1. list the total qty of each item (i.e across all stores)
> 2. list the QTY of a certain item within each store
> 3. list all items, their qty for a specific store
>
> ...I could smash this out in SQL in a few minutes...but cant get my head
> around doing it as documents....eg would I have a document for each 
store
> containing product attributes(i.e p1, p2 etc)? or a document for each
> product containing store attributes(i.e P > s1-qty, s2-qty, s3-qty)?
>
> or (and i doubt this be true) would i have separate store docs and 
product
> docs and somehow link then like I would in a 'real' (:-p) database lol
>
> wasnt sure if these kinds of Q's were asked in here so thought id just
> give it a shot
>

Re: business model / 'ER' help

[Randall Leeds <ra...@gmail.com>]

The easiest thing in my mind would be to have a document for each
inventory item that contains its name and the store where it's in
stock.
This is actually kinda nice because it lets you track individual
instances of each item, like if you wanted to order the item to be
sent from one store to another you could modify the store property.

I think you can get away with only two map functions.
Make one map that emits a key like {[item, store]: item_id}. Call it
"items_by_name".
Another map emits keys like {[store, item]: item_id}. Call it "items_by_store".
Then all three of your questions are simple summation ({"reduce":
"_count"}) reductions.

1. _design/inventory/_view/items_by_name?group=true&group_level=1
2. _design/inventory/_view/items_by_name?group=true&group_level=2&startkey="[item_name]"&endkey="[item_name,
{}]"
3. _design/inventory/_view/items_by_store?group=true&group_level=2&startkey="[store_name]"&endkey="[store_name,
{}]"

I think this would work for you. You might need to url encode those keys.
The startkey and endkey parameters are chosen based on the collation
specification[1].

Happy map(-reduc)ing!
-Randall

[1] http://wiki.apache.org/couchdb/View_collation?action=show&redirect=ViewCollation#Collation_Specification

On Mon, May 31, 2010 at 20:14,  <St...@nextgen.net> wrote:
> Hi I am trying to get my head around a simple practice task, however I
> can't stop thinking about relational models as opposed to document models
> hehe
>
> ok so i have one couchDB database that has to contain 3 stores, each store
> has a product inventory (i.e product name, qty)
>
> I have to be able to:
>
> 1. list the total qty of each item (i.e across all stores)
> 2. list the QTY of a certain item within each store
> 3. list all items, their qty for a specific store
>
> ...I could smash this out in SQL in a few minutes...but cant get my head
> around doing it as documents....eg would I have a document for each store
> containing product attributes(i.e p1, p2 etc)? or a document for each
> product containing store attributes(i.e P > s1-qty, s2-qty, s3-qty)?
>
> or (and i doubt this be true) would i have separate store docs and product
> docs and somehow link then like I would in a 'real' (:-p) database lol
>
> wasnt sure if these kinds of Q's were asked in here so thought id just
> give it a shot
>