Comments on: The Mother of All Database Normalization Debates http://www.grok.in/blog/2008/07/25/the-mother-of-all-database-normalization-debates/ (ignorance killed the cat, curiosity was framed) Wed, 16 Jun 2010 18:48:41 +0000 hourly 1 By: Nathan http://www.grok.in/blog/2008/07/25/the-mother-of-all-database-normalization-debates/comment-page-1/#comment-469 Nathan Thu, 04 Jun 2009 06:46:09 +0000 http://www.grok.in/?p=51#comment-469 Normalization is nothing just read the following link http://sqldbsolution.blogspot.com/2009/06/normalization-is-first-step-for-db.html By nathan Normalization is nothing just read the following link

http://sqldbsolution.blogspot.com/2009/06/normalization-is-first-step-for-db.html

By nathan

]]> By: Edward M. Goldberg http://www.grok.in/blog/2008/07/25/the-mother-of-all-database-normalization-debates/comment-page-1/#comment-417 Edward M. Goldberg Mon, 29 Dec 2008 23:10:19 +0000 http://www.grok.in/?p=51#comment-417 You can do both! Normalize the Master or Origin information and De-Normalize of the deployment of the information that is used for look-ups. We do this all of the time and real life. The information we USE is a De-Normalized version of the database for most re-life uses. For example out day-timer. The internal version may be very folded or normalized. The bank creates a De-normalized version of information on paper as a backup for bank use if the database is down and as a cross reference. Do the same for your applications. For example, once a day compile the "stats" that the user sees on the web page from the Normalized internal schema. Let the user know that this is a "once a day" roll up of the stats. Now the action needed for this web page will be VERY fast. The over head low. You have a fast solution. The information is NOT real time, but the user gets a quick reply. Edward M. Goldberg http://Blog.EdwardMGoldberg.com You can do both!

Normalize the Master or Origin information and De-Normalize of the deployment of the information that is used for look-ups.

We do this all of the time and real life. The information we USE is a De-Normalized version of the database for most re-life uses. For example out day-timer. The internal version may be very folded or normalized.

The bank creates a De-normalized version of information on paper as a backup for bank use if the database is down and as a cross reference.

Do the same for your applications. For example, once a day compile the “stats” that the user sees on the web page from the Normalized internal schema. Let the user know that this is a “once a day” roll up of the stats. Now the action needed for this web page will be VERY fast. The over head low. You have a fast solution. The information is NOT real time, but the user gets a quick reply.

Edward M. Goldberg
http://Blog.EdwardMGoldberg.com

]]> By: sappani http://www.grok.in/blog/2008/07/25/the-mother-of-all-database-normalization-debates/comment-page-1/#comment-410 sappani Tue, 23 Dec 2008 00:39:46 +0000 http://www.grok.in/?p=51#comment-410 yenna mame, sappunu oru matter ah solli irukka.... yenna mame, sappunu oru matter ah solli irukka….

]]> By: Thejesh GN http://www.grok.in/blog/2008/07/25/the-mother-of-all-database-normalization-debates/comment-page-1/#comment-393 Thejesh GN Tue, 28 Oct 2008 08:34:42 +0000 http://www.grok.in/?p=51#comment-393 Normalization is a double sided sword. You need to know when to stop normalizing. I had a case where I had to join the same table again and again ( table joined with the same table) to get few rows of data. The app performance was pathetic just because of complex queries. (due to highly normalized tables) Normalization is a double sided sword. You need to know when to stop normalizing.

I had a case where I had to join the same table again and again ( table joined with the same table) to get few rows of data. The app performance was pathetic just because of complex queries. (due to highly normalized tables)

]]>