Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database Modeling- Normalization - Dinosaurs or What?

RE: Database Modeling- Normalization - Dinosaurs or What?

From: <Paula_Stankus_at_doh.state.fl.us>
Date: Mon, 24 Mar 2003 19:14:11 -0500
Message-Id: <24765.322950@fatcity.com>


This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F263.76342C50
Content-Type: text/plain;

        charset="iso-8859-1"

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

------_=_NextPart_001_01C2F263.76342C50
Content-Type: text/html;

        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: Database Modeling- Normalization - Dinosaurs or =
What?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Guys,</FONT>
</P>

<P><FONT SIZE=3D2>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 &quot;object-oriented&quot; when = it truly is not.&nbsp; Let us just say that it is highly = denormalized.&nbsp; 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.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>I have been losing this battle.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>So - what is your experience with this?</FONT>
</P>

<P><FONT SIZE=3D2>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</FONT></P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>It turns my stomach but then I wonder about my own =
sanity - am I making too much out of nothing?&nbsp; What about these = stovepipe systems?&nbsp; </FONT></P>

<P><FONT SIZE=3D2>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.&nbsp; Developers = are aghast at the performance implications.&nbsp; 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.&nbsp; They say mostly batch inserts/updates and batch reads - = but then they say some OLTP.&nbsp; This is a SQL Server database.&nbsp; = I think the separate reference tables provides only way for = extensibility and data integrity.&nbsp; I say I will write for them a = joined view.&nbsp; They say perf. implications.&nbsp; - = AARRRGGHH!</FONT></P> Received on Mon Mar 24 2003 - 18:14:11 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US