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.
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.
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).
