In order to DENORMALIZE, you need to have NORMALIZED schema in the first place (and only then go on with "denormalization" business).
Igor Neyman, OCP DBA [EMAIL PROTECTED] ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Tuesday, March 25, 2003 11:24 AM > Stephane - I think both you and Tom are right. Report writers like systems > that are somewhat denormalized. But according to Paula it sounded like her > developers didn't even understand normalization to begin with. I think there > is normalization, denormalization, and "doesn't have a clue". I may have > made a hasty assumption, but it sounded like this was the latter situation. > > > > Dennis Williams > DBA, 40%OCP, 100% DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > -----Original Message----- > Sent: Tuesday, March 25, 2003 9:24 AM > To: Multiple recipients of list ORACLE-L > > > DBA are responsible for the data model. > I spend time to show the developpers the benefits of data normalization. > > I do not agree with Tom on "A good data model produces good opportunities > for all kinds of data retrieval tools in the later life of the application." > as I just did a performance review of a Decision Support System and my > conclusion is that the data model is too normalized for a query intensive > usage. > It depends on what the system will be use for. For OLTP, yes third normal > form is good. For datawarehousing, a star schema is the way to go. > > > Stephane > > -----Original Message----- > Thomas F > Sent: Tuesday, March 25, 2003 7:47 AM > To: Multiple recipients of list ORACLE-L > > > Paula, > > Keep fighting for normalization. Something almost all developers fail to > recognize is the long-term use of the database - they only think in the > "here and now" - they need to develop the application right now. What they > fail to recognize are the poor untrained users down the line who will need > to develop reports off of the data. Having denormalized data will cause > tons data inconsistencies in a few years - exactly what we had back in the > "good old Cobol flat file days". A real mess. > > One of the most important jobs that a DBA has is producing a good data model > keeping all players and users in mind when designing the tables. A good > data model produces good opportunities for all kinds of data retrieval tools > in the later life of the application. > > Hope this helps. > > Tom Mercadante > Oracle Certified Professional > > -----Original Message----- > Sent: Monday, March 24, 2003 7:14 PM > To: Multiple recipients of list ORACLE-L > > > > Guys, > > The emphasis in many places I have worked is developing quick and dirty > systems as quickly as possible and working with developers that don't seem > to have very much understanding of Relational Database Theory but who prefer > to program using flat files in relational databases - calling it > "object-oriented" when it truly is not. Let us just say that it is highly > denormalized. As a DBA I care about data integrity, extensibility and > scalability but the up and coming esp. SQL Server developer types seem to > operate in a world where this doesn't matter - just buy more hardware, > denormalize to make the programming easier, etc. > > I have been losing this battle. > > So - what is your experience with this? > > What about the idea of having everyone access all objects in the views so > that if need be the DBA's could in fact still make physical changes to the > schemas without a large amount of rewriting of code? - as a standard > > Living without normalization for most things - esp. small systems and w/o > fk's except as they are maintained in the application for the sake of > getting the application done quickly, cheaply. > > It turns my stomach but then I wonder about my own sanity - am I making too > much out of nothing? What about these stovepipe systems? > > Case in-point 100,000 row table for asset management - moving different > types of addresses to a separate address table and moving different types of > people to a person table. Developers are aghast at the performance > implications. I am thinking perf. implications not real esp. with small > amount but provides extensibility and RI with these reference tables instead > of denorma. in multiple tables. They say mostly batch inserts/updates and > batch reads - but then they say some OLTP. This is a SQL Server database. > I think the separate reference tables provides only way for extensibility > and data integrity. I say I will write for them a joined view. They say > perf. implications. - AARRRGGHH! > > Oracle OCP DBA > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: DENNIS WILLIAMS > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Igor Neyman INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
