From: sjm@bcrki65.bnr.ca (Stuart MacMartin)
Newsgroups: comp.databases
Subject: Re: Data Base design pet peeve
Date: 28 Sep 92 14:29:08 GMT
Organization: Bell-Northern Research Ltd., Ottawa, Canada

In article <1992Sep25.140930.24262@linus.mitre.org> vv@mbunix.mitre.org (Ventrone) writes:
>In article <66577@cup.portal.com> DonD@cup.portal.com (Don Robert DeCosta) writes:
>>I say, "Hey, if I only have 100 customers I'm going out of business!"
>>Let's say we have 30000 customers, I say make it a 2 byte integer!  Why
>>would I want to use 5 bytes to store "30000" when I could use 2 bytes
>>to store it as 30000?

>>Like I said this has come up before, this simple, "If you don't perform
>>math on it, make it alpha" logic... I think it's totally wrong!
>
>There are obviously pros & cons here, and it seems to boil down to a trade-off
>between processing efficiency and the notion of approximating a "user-defined"
>data type (in this case, using character string since it's closer to the 
>abstract idea of a customer number than an integer is.)

TRADEOFFS.  The problem here is that the requirements are not clearly stated.
1.  Modelling.  Simplicity, ease of understanding and use, extensibility.
                "The shape of the solution should match the shape of the
                problem" (to quote one instructor of an OOA course)
2.  Machine limitations.  Speed, disk space.

In this case, the instructor seems to have totally ignored point #2.
In an ideal world, point #1 would be the only factor.  However, this
is rarely an ideal world.  I have seen examples where there were several
equally acceptable ways of doing things if you considered only #1, but
for which one was vastly superior (and another vastly inferior) when
you considered the machine and database limitations.

You, on the other hand, seem totally concerned with point #2.  In many
cases, this is misplaced.  I have seen several cases where clarity and
maintainability have been sacrificed for nonexistant optimization.  Just
because you save space on one field does not mean that you save any
space in the database.  It all depends.  And even if you do save space,
that space might not be significant.

What you really need to do is understand your requirements (including your
constraints).  The solution may be different depending on what you need!

But one thing I don't understand in your example.  In what way is this
arbitrary number useful?  Why is it visible?  It doesn't have much bearing
to anything in the real world.  Are customer numbers really the right
approach?  Do you really find your customers through some number?   So,
I don't even buy your instructor's argument about point#1: modelling.

[I hate customer numbers!  Every number that I have, I need another
card for, cluttering up my wallet.  And if I was a business, I would 
want my business name to identify me.  Customer numbers are object ids
that should be totally hidden from both me and you!]

Stuart
--
: Stuart MacMartin                                    email: sjm@bnr.ca      :
: Bell-Northern Research                              phone: (613) 763-5625  :
: PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :