Path: utzoo!dciem!nrcaer!sce!cognos!nigelc From: nigelc@cognos.UUCP (Nigel Campbell) Newsgroups: comp.databases Subject: Re: Join Contest Message-ID: <8609@cognos.UUCP> Date: 18 Jul 90 01:43:15 GMT References: <5265@plains.UUCP> <12072@blia.BLI.COM> Reply-To: nigelc@cognos.UUCP (Nigel Campbell) Distribution: comp Organization: Cognos Inc., Ottawa, Canada Lines: 46 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >In article <12072@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes: > > My observation is that the number of tables used by an application > increases dramaticly if the database design is well normalized. > >Is that good or bad? (Speaking from your observations that is :-) From my own relational / non relational experiences the gains frequently have outweighed the losses 1. you usually have small record sizes so most systems caches perform well 2. you reduce the locking (often) that a non-normalised system would experience 3. transactions tend to become more simpler and thus easier to model and maintain in the language and probably in most case tools 4. you also can model time very easily even if originally historical data was not a system requirement . Denormalisation helps when necessary however so often I have reviewed applications where the programmers spent more time coding around the design thus increasing the cost of the system . You really have to weigh up the pros and cons of not going to 3rd or Bcnf . The only hassle we have faced occasionaly is when an end user wants to write his own reports and then is faced with how to traverse reference tables etc to flesh out his report . Views obviously come to the rescue in relational however in say an RMS based system you have to help provide a similar interface . One client we have (On a Data General) did find that the query optimiser for the resident dbms made some very odd optimizations which killed the view processing he defined.They originally opted to collapse the tables and then found that by altering the stats on the tables that they could fool the optimiser into a more optimial query . -- Nigel Campbell Voice: (613) 783-6828 P.O. Box 9707 Cognos Incorporated FAX: (613) 738-0002 3755 Riverside Dr. uucp: nigelc@cognos.uucp || uunet!mitel!sce!cognos!nigelc Ottawa, Ontario CANADA K1G 3Z4