Re: database model tshirt sizes

From: "NbForYou" <nbforyou(at)hotmail(dot)com>
To: <me(at)alternize(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>, <PHatcher(at)macys(dot)com>
Subject: Re: database model tshirt sizes
Date: 2006-03-19 17:43:53
Message-ID: BAY107-DAV6CB34D10AE32002682FF9DBDA0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

So a default value for all products would be size:"all"

for example, the same tshirt shop also sells cdroms.

It size attribute would be to place it to be :"all". (because we cannot
place an uniqe index on null values)

But the industry evolves and so in time the same cdrom is now available for
pc and playstation.

So i would like to have it as 1 productid but with different attributes: pc
(with quantity 5) and playstation (with quantity 3).
So when I do an insert for this 2 products with 1 productid it would be
like:

insert into versions (productid,size,quantity) values (345,'pc',5);
insert into versions (productid,size,quantity) values (345,'playstation',3);

if however the product existed we get an error:

because the default value version "all" did also exist and is now obsolete

population versions:
================

productid: 123, versionid: 1, color: 'black', size: 'all', quantity: 11
productid: 442, versionid: 2, color: 'yellow', size: 'l', quantity: 1
productid: 442, versionid: 2, color: 'yellow', size: 's', quantity: 4
productid: 442, versionid: 2, color: 'red', size: 'xl', quantity: 9
productid: 442, versionid: 2, color: 'blue', size: 's', quantity: 0
productid: 345, versionid: 3, color: null, size: 'all', quantity: 15
productid: 345, versionid: 3, color: null, size: 'pc', quantity: 5
productid: 345, versionid: 3, color: null, size: 'playstation', quantity: 3

WOULD HAVE TO BE:

population versions:
================

productid: 123, versionid: 1, color: 'black', size: 'all', quantity: 11
productid: 442, versionid: 2, color: 'yellow', size: 'l', quantity: 1
productid: 442, versionid: 2, color: 'yellow', size: 's', quantity: 4
productid: 442, versionid: 2, color: 'red', size: 'xl', quantity: 9
productid: 442, versionid: 2, color: 'blue', size: 's', quantity: 0
productid: 345, versionid: 3, color: null, size: 'pc', quantity: 5
productid: 345, versionid: 3, color: null, size: 'playstation', quantity: 3

ALSO:

what is versionid used for?

----- Original Message -----
From: <me(at)alternize(dot)com>
To: "NbForYou" <nbforyou(at)hotmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>;
<pgsql-performance-owner(at)postgresql(dot)org>
Sent: Sunday, March 19, 2006 3:37 PM
Subject: Re: [PERFORM] database model tshirt sizes

> another approach would be:
>
> table product:
>> productid int8 PK
>> productname charvar(255)
>
> table versions
>> productid int8 FK
>> versionid int8 PK
>> size
>> color
>> ...
>> quantity int4
>
> an example would be then:
>
> table product:
> - productid: 123, productname: 'nice cotton t-shirt'
> - productid: 442, productname: 'another cotton t-shirt'
>
> table versions:
> - productid: 123, versionid: 1, color: 'black', size: 'all', quantity: 11
> - productid: 442, versionid: 2, color: 'yellow', size: 'l', quantity: 1
> - productid: 442, versionid: 2, color: 'yellow', size: 's', quantity: 4
> - productid: 442, versionid: 2, color: 'red', size: 'xl', quantity: 9
> - productid: 442, versionid: 2, color: 'blue', size: 's', quantity: 0
>
>
> that way you can have more than 1 quantity / color / size combination per
> product and still have products that come in one size. so instead of only
> using a 2nd table for cases where more than one size is available, you
> would always use a 2nd table. this probably reduces your code complexity
> quite a bit and only needs 1 JOIN.
>
> - thomas
>
>
>
> ----- Original Message -----
> From: "Patrick Hatcher" <PHatcher(at)macys(dot)com>
> To: "NbForYou" <nbforyou(at)hotmail(dot)com>
> Cc: <pgsql-performance(at)postgresql(dot)org>;
> <pgsql-performance-owner(at)postgresql(dot)org>
> Sent: Sunday, March 19, 2006 2:59 PM
> Subject: Re: [PERFORM] database model tshirt sizes
>
>
>> We have size and color in the product table itself. It is really an
>> attribute of the product. If you update the availability of the product
>> often, I would split out the quantity into a separate table so that you
>> can
>> truncate and update as needed.
>>
>> Patrick Hatcher
>> Development Manager Analytics/MIO
>> Macys.com
>>
>>
>>
>> "NbForYou"
>> <nbforyou(at)hotmail
>> .com> To
>> Sent by: <pgsql-performance(at)postgresql(dot)org>
>> pgsql-performance cc
>> -owner(at)postgresql
>> .org Subject
>> [PERFORM] database model tshirt
>> sizes
>> 03/18/06 07:03 AM
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hello,
>>
>> Does anybody know how to build a database model to include sizes for
>> rings,
>> tshirts, etc?
>>
>>
>> the current database is built like:
>>
>> table product
>> =========
>>
>> productid int8 PK
>> productname charvar(255)
>> quantity int4
>>
>>
>> what i want now is that WHEN (not all products have multiple sizes) there
>> are multiple sizes available. The sizes are stored into the database. I
>> was
>> wondering to include a extra table:
>>
>> table sizes:
>> ========
>> productid int8 FK
>> size varchar(100)
>>
>>
>> but then i have a quantity problem. Because now not all size quantities
>> can
>> be stored into this table, because it allready exist in my product table.
>>
>> How do professionals do it? How do they make their model to include sizes
>> if any available?
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dave Page 2006-03-19 18:19:40 Re: Best OS & Configuration for Dual Xeon w/4GB &
Previous Message Antoine 2006-03-19 15:34:39 Re: n00b autovacuum question