I know but seem to have to work with developers these days who don't understand the basics of normalization and the tradeoffs - lack of data integrity, lack of extensiblity. Saying to them and even showing them data integrity issues doesn't seem to convince them. They always say - we will handle that in the application. To me it isn't handled in the database it isn't really taken care of and why replicate in application code what is already part of the underlying RDBMS - but then they start getting personal.
Oracle OCP DBA
-----Original Message-----
From: Robson, Peter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 25, 2003 11:39 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?
Just a couple of comments here, Dennis.....
> -----Original Message-----
> From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]]
> Sent: 25 March 2003 14:29
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Database Modeling- Normalization - Dinosaurs or What?
>
>
> Paula
> I think their use of the term "object-oriented" maybe be
> incorrect. That
> said, some new converts to object-oriented get carried away.
> Some even want
> to use Oracle in an object-oriented manner. In an effort to
> please everyone,
> Oracle has even added object-oriented features to tables. I
> don't think they
> are used much.
Indeed, some very experienced Oracle users advice against using these
extensions.
> As Tom points out, the data model will need to support
> many purposes.
> One is reporting. If you don't normalize your data model,
> then it will be
> difficult or impossible to create reports.
In fact, if you don't normalise, you will be unable to guarantee the
integrity of your data, and that is far worse!
peter
edinburgh
>
>
>
> Dennis Williams
> DBA, 40%OCP, 100% DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED]
>
> -----Original Message-----
> Sent: Monday, March 24, 2003 6: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).
>
*********************************************************************
This e-mail message, and any files transmitted with it, are
confidential and intended solely for the use of the addressee. If
this message was not addressed to you, you have received it in error
and any copying, distribution or other use of any part of it is
strictly prohibited. Any views or opinions presented are solely those
of the sender and do not necessarily represent those of the British
Geological Survey. The security of e-mail communication cannot be
guaranteed and the BGS accepts no liability for claims arising as a
result of the use of this medium to transmit messages from or to the
BGS. The BGS cannot accept any responsibility for viruses, so please
scan all attachments. http://www.bgs.ac.uk
*********************************************************************
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Robson, Peter
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).
