Re: Designing a database

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