On Sun, Apr 22, 2001 at 01:28:34AM -0500, Phil Jackson wrote:
> Good Point, Richard - sensible normalization - if duplicating a value
> here and there saves you from having to reference 12 tables instead of
> 3, yes, by all means. Also, adapting some standards as to using
> meaningfull names for columns - if fieldWidgetSize is char(25) - don't
> call it something else if it appears elsewhere - and don't change it's
> type!
>
> Phil J.
>
>
>> Don't, however, go overboard with trying to normalize your database.
>> Don't get me wrong: normalization is good because it saves disk and
>> memory space (and is quite elegant as well); however, too much
>> normalization can come at a price in PHP in terms of application speed
>> and server overhead (not to mention creating coding nightmares if
>> you're using your web-based application to enter data into your
>> database as well as pull information from it).
I asked this a year or so ago, but never did receive a "practical" reply
that I could understand. So I'll give it another shot...
What are the "nuts-and-bolts" of normalization? In a "practical" sense,
how do you guys go about doing it? Do you create a spreadsheet or
something, and start creating 'test' tables and see how they pan out?
I understand what the 'goal' of normalization is suppose to be, I just
never stumbled on a method of achieving it. Know what I mean?
Tia...
--
-duke
Calgary, Alberta, Canada
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
