Thank you very much for explaining so clearly. I have read that performance may be affected when normalising beyond the 3rd normal form.
In the context of my reply a table with pleanty of columns was being used - 168 columns or so if I remember right. My assumption was that normalisation would result in some frequently accesed columns joined to form simpler tables, and quite of lot of less used columns would form another set of tables, which may result in quite a lot of performance improvement in some cases,but a precise answer can be found only when we know the db-engine dependency on access-speed for fewer number of columns vs >=1 joins. But you said it is always to better to evaluate the View-Struts-Action_class analysis first, especially if database cannot be changed. Merry Christmas and Happy New Year to All of You in Advance. Thanks & regards, Manu Francis Mathew, 9742260423. Team Lead - Accenture. www.accenture.com ________________________________________ From: Dave Newton [davelnew...@gmail.com] Sent: Wednesday, December 22, 2010 10:33 AM To: Struts Users Mailing List Subject: Re: web application response time is too large. On Tue, Dec 21, 2010 at 11:56 PM, wrote: > Are you sure that database is normalised as well.. > Normalization can often *increase* response time, particularly for some types of operations, because of the join overhead. The DB needs to be correct for what it's being used for, and sometimes normalization isn't the best approach. (Although I try to isolate that kind of stuff behind triggers and a reporting table since that's where I often run in to it. But over-normalization can be a performance drag under some circumstances.) Dave This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
