On 24 Nov 2004 01:52:52 -0500, Greg Stark <gsstark@mit.edu> wrote:
> Alexandre Leclerc <alexandre.leclerc@gmail.com> writes:
>
> > Thanks for those tips. I'll print and keep them. So in my case, the
> > product_code being varchar(24) is:
> > 4 bytes + string size (so possibly up to 24) = possible 28 bytes. I
> > did the good thing using a serial. For my shorter keys (4 bytes + up
> > to 6 char) I will use the natural key.
>
> Realize that space usage is really only part of the issue.
Thank you for this additionnal information. This will help out in the
futur. In my situation this is a good thing to have integer key where
I decided to have them. Event if I was obliged to add UNIQUE
constraints to some other columns. I think they call this "candidate
key" and it's still 3NF (whatever; but only if my db is correctly
organised)... I try to be logical and efficient for good performance.
But in the end, the time (the db will get bigger) and good EXPLAIN
ANALYSE commands will help fine tuning later! This will give me more
experience at that point.
> Actually I see one interesting exception to my policy in my current database
> schema. And I don't think I would do this one differently given the choice
> either. The primary key of the postal code table is the postal code. (postal
> codes are up here in the great white north like zip codes down there.)
(I do understand this one, living in the province of Quebec. ;) And
the great white north is still not arrived; end november! - Still, not
very exceptionnal.)
Regards.
--
Alexandre Leclerc
