Re: Database Design questions

  • From: <jtesta@xxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 18 Jun 2004 09:55:17 -0400 (EDT)

Denormalization has its place and time, but i'm not sure this is what you
want here, if you dig into the concepts of modeling gurus, kimball, etc,
you'll see that you should break those out and try to eliminate redundant
data.  Your question is a bit open ended, are you trying to aatian 3rd
normal form, is it oltp, olap, warehouse, etc.  As for performance,


original message below

 Hi Design Experts,

     I am in the process of designing a  datamodel for
 a new application and I need some advice regarding
 that. I have a table with almost 130 columns in it.
 This table gets updated with new information regularly
 and all the columns are mostly dependent or related to
 the primary key. I think there will be a poor
 performance with the table of this size. My question
 is it better of breaking this table into several
 different tables like

 property_details ( prop_id (pk), prop address, bed
 rooms,bath rooms ,total sqft ...)
 property_auctions ( prop_id (fk), auction date,
 auction location..)
 property_loans, (prop_id (fk), loan date, loan amount,
 loan recording date...)
 property_defendents  (prop_id (fk), defendent owner
 firstname, lastname, company name ...)

 Each of these tables will have prop_id as a Foreign
 Key (which is also a primary key for that table )
 referencing the prop_id  Primary Key in this case
 parent table property_details.

 1) Is this a good design for such a big table size ?
 2) If I choose this approach and when i need to get
 all the information for a property I will end up
 querying all the tables and will  involve joining all
 the tables, which would also affect the performance of
 the query.

 Can anyone help please help me with the problem ?
 Below you will see the huge table which I am talking


<table desc snipped>

Please see the official ORACLE-L FAQ:
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
Archives are at
FAQ is at

Other related posts: