Riman Teji said..
Generally we denormalize relational database tables to improve processing performance for data insertions, deletions and selection. A fully normalized database schema can fail to provide adequate system response time due to excessive table join operations.
But a clean, normalized database should always give a good performance, as well as preserve data integrity. Denormalization may solve one part of dealing with performance (speed of accessing the data), but it creates possible performance problems in several other areas. Total performance impact must be evaluated.
So you need to perform a detailed view analysis in order to identify situations where an excessive number of table joins appears to be required to produce a specific end-user view.
So you need to perform a detailed view analysis in order to identify situations where an excessive number of table joins appears to be required to produce a specific end-user view. While no hard rule exists for defining "excessive," any view requiring more than three joins should be considered as a candidate for denormalization. Beyond this, system performance testing by simulating the production environment is necessary to prove the need for denormalization.
The database designer should attempt to reduce the number of foreign keys in order to reduce index maintenance during insertions and deletions. Reducing foreign keys is closely related to reducing the number of relational tables.
The ease of data maintenance provided by normalized table structures must also be provided by the denormalized schema. Thus, a satisfactory approach would not require excessive programming code (triggers) to maintain data integrity and consistency.