|WikiProject Databases / Computer science||(Rated High-importance)|
Merge with Normalization?
- I and a few others have been editing Database normalization recently to split it up into separate articles for each normal form. Now that's happened, it'd probably be best to keep this article as the main article for denormalization, with a link from the database normalization article. --VinceBowdren 18:36, 21 August 2006 (UTC)
Preferred Database Design?
Why does the author state that the "preferred" design for better query access is to use materialized views? In the next paragraph he states the more usual approach is to denormalize in the database design. If this approach is "more usual" than the former cannot be the preferred approach, can it? --188.8.131.52 22:32, 31 March 2006 (UTC)
- This is definitely POV, but I'm not sure of the terminology to fix it. Perhaps replace "preferred" by describing the method as more of a "back-end" method performed internally by the DBMS software, while denormalization is a "front-end" method performed by the person designing the database structure. This may cause confusion with other uses of the back-end and front-end terms, however. I do agree that some cleanup of this article is needed. Maybe I'll come back and see how it looks after finishing a couple more courses. :) Maghnus 17:16, 14 September 2007 (UTC)
If you are going to present some design as the "preferred method" then there should definitely be a citation for that, regardless of whether it is true or not --unsigned
Some more explanation needed
- It is sometimes necessary because current DBMSs implement the relational model poorly.
Why is denormalization needed, if the DBMS implements the relational model poorly? I feel that some reference is needed there. Maybe some links to some study about how bad (or good) dbms adhere to the releational modem, would be interesting. 184.108.40.206 (talk) 10:45, 19 February 2008 (UTC)
Denormalization a sign of bad DB architecture??
Giving DBA's explicit ability to chose what level of denormalization to use instead of reserving it to the DB software seems like an explicit architectural choice that will allow immensely greater scalability while only offering moderate addition to complexity. There are so many other, more important problems to solve in CS than how DB software can guess usage patterns before-hand for minimal gain. —Preceding unsigned comment added by 220.127.116.11 (talk) 04:24, 29 February 2008 (UTC)
Normalized implies heavy load?
This lead-paragraph statement makes an amazingly-broad claim:
- “A relational normalised database imposes a heavy access load over physical storage of data even if it is well tuned for high performance.”
To me, this looks like a POV bias against normalization, so I've tagged it as such. At the very least, it would need to cite a credible source which asserts that access load is “heavy”, regardless of other factors, as a consequence of a database being normalized. 18.104.22.168 (talk) 22:55, 25 October 2012 (UTC)
British vs. American spelling
Can we agree on the spelling, normalization vs. normalisation, and be consistent throughout? I will not attempt a change now, and hope someone more authoritative can do it. Thanks. — Preceding unsigned comment added by 2001:620:8:3E82:8000:0:0:14C3 (talk) 18:55, 11 December 2012 (UTC)
- I agree, and made the change, but as a BOLD change to make the text of the article consistent with the title, rather than an authoritative one. However I do note that E. F. Codd introduced the inverse term as "normalization" in his seminal 1969 paper, "A Relational Model of Data for Large Shared Data Banks": "There is, in fact, a very simple elimination procedure, which we shall call normalization." Shunpiker (talk) 14:32, 19 December 2012 (UTC)