dcsimg
Login | Register   
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Tip of the Day
Language: SQL Server
Expertise: Beginner
Mar 24, 1997

WEBINAR:

On-Demand

Application Security Testing: An Integral Part of DevOps


Normalized Database: When to Split?

Question:
We have several heavily-used tables with lots of columns (average around 30 columns), and the users are getting locked out frequently. We've thought about splitting the tables, but didn't want to sacrifice all the work we put into normalizing them. Any thoughts?

Answer:
Although normalized databases are the ideal in theory, sometimes it is necessary to de-normalize. If you can split the larger tables into two or more smaller tables without duplicating information (except for the primary key, of course), that would be ideal. But if you have to duplicate some information, make sure that you grant update and insert privileges of that data in only one table. I know it's hard to de-normalize after going through the normalization process (all that work!), but if you start with normalized databases, and if you take care to protect the data integrity of any duplicate columns, you would be able to re-normalize easily if it were ever needed (and a simple join or view can recreate the appearance of the normalized data).

DevX Pro
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date