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, joe 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 about. Thanks! Pallav. <table desc snipped> ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------