On Mon, Mar 20, 2006 at 08:38:15PM -0500, Jaime Casanova wrote: > On 3/20/06, Craig A. James <[EMAIL PROTECTED]> wrote: > > Design 1: > > create table a ( > > id integer, > > frequently_updated integer); > > > > create table b( > > id integer, > > infrequently_updated_1 integer, > > infrequently_updated_2 integer, > > infrequently_updated_3 integer, > > ... etc. > > infrequently_updated_99 integer); > > > > Design 2: > > create table c( > > id integer, > > frequently_updated integer, > > infrequently_updated_1 integer, > > infrequently_updated_2 integer, > > infrequently_updated_3 integer, > > ... etc. > > infrequently_updated_99 integer); > design 1 is normalized and better > design 2 is denormalized and a bad approach no matter the RDBMS
How is design 1 denormalized? > "What they (MySQL) lose in usability, they gain back in benchmarks, and that's > all that matters: getting the wrong answer really fast." > Randal L. Schwartz Where's that quote from? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(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
