What is Digg?Sponsored by Dragon Age: Origins
Follow the Dragon Age: Origins development team on Twitter view!
twitter.com/DragonAge - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
52 Comments
- edzieba, on 10/12/2007, -1/+35'Normalise' is the original English spelling, 'Normalize' is the Americanisation. Or should that be Americanization? ^_^
- paulmdx, on 10/12/2007, -2/+21You also seem to be in need of a new keyboard without a stuck caps lock. ;-)
- fredrated, on 10/12/2007, -1/+12Yes, someone needs to normalize this article. It keeps repeating itself over and over.
- slantyyz, on 10/12/2007, -0/+10The blanket statement that normalization of a relational database is "all good" is highly misleading. There are many cases where denormalization is a good thing. A normalized schema is definitely a BAD thing if you are doing reporting on large volumes of data while performing aggregate functions on them. That is why data warehouses contain denormalized data.
- johnsto, on 10/12/2007, -3/+13If someone is designing databases and they don't know what normalising is, they shouldn't be designing databases, and certainly shouldn't be paid for it.
That's what I was taught anyway. Normalising isn't just to make things quicker, it helps development, reduces duplication, and contributes to better, safer and more stable code with fewer database-related bugs. - geronimo, on 10/12/2007, -0/+8As soon as you start joining over 5 tables in a query, the query optimization in all databases start to think real hard, sometimes too hard. In postgres, if you join 5 or more tables(configurable), it starts using genetic algorithms to determine the best query plan. Which means it can work really well or not work well at all. Mysql just flat breaks down if you throw in too many joins, this might have changed recently.
In any case, when you have a beautiful normalized schema requiring a large number of joins per query then you'll soon find out it ain't all that pretty. I'm surprised so many developers aren't aware of basic DB optimization. I am currently the archtect, developer, DBA, administrator... If you specialize in any one thing then you will neglect other important aspects and become 'corporate'.. your code will be slow, you'll have more meetings about the slowness and you'll be inefficient. Everything is so interconnected, you have to pay attention to everything. - ShaiHulud, on 10/12/2007, -1/+8That's very true, but it does assume you've normalized your DB first. After all, you can't undo what you haven't done in the first place.
Denormalization on a DB that isn't normalized is better know as 'making it worse'. - timeblind, on 10/12/2007, -1/+7Yes, someone needs to normalize this article. It keeps repeating itself over and over.
- paulmdx, on 10/12/2007, -1/+7"You would have to be plain stupid to do it inefficiently."
You're right. You never see hideously inefficient badly designed databases.... Oh no, wait.. - xero9, on 10/12/2007, -2/+7UPDATE Users SET Mod = Mod+1 WHERE User = 'YellowBook'
Affected rows: 1
Time: 0.063ms - kaemaril, on 10/12/2007, -0/+5Amen. I was supplied (from our development team) a fully normalised database design that worked like a dog. I was able to demonstrate a few simple denormalisations that sped things up by around 95%, but - for some bizarre reason - the developers weren't interested. They were convinced the database design had to be 'fully normalised' and that was that.
Six months down the line they're back to me (DBA) asking why the database is so slow and unresponsive. My response? 'I told you why six months ago' ... then I fixed it for them :) - Railer, on 10/12/2007, -1/+6I don't get why this made it to the top of digg? There is a 100 articles like this on the Internet. You want much better ones I recommend:
http://en.wikipedia.org/wiki/Database_normalization
http://www.openwin.org/mike/index.php/presentations/introduction-to-database-normalization/
http://www.geekgirls.com/ - kaemaril, on 10/12/2007, -2/+6I think you're in the wrong story, dude.
- YellowBook, on 10/12/2007, -5/+9SELECT * FROM DiggArticles
WHERE IntelligenceLevel > 0
0 rows returned. - kaemaril, on 10/12/2007, -2/+6I'm guessing because ... people found it interesting and voted it up?
- DannoHung, on 10/12/2007, -0/+4Bah, doesn't even go into the 4th or 5th Normal Forms (which are really, REALLY confusing).
- crilen007, on 10/12/2007, -0/+4Oh great, now everyone at my work will think they are a Database Expert. Thanks ozguralaz.
- recursive, on 10/12/2007, -1/+4UPDATE Comments SET Mod = Mod+1 WHERE CommentID = 2337015
- smedstadc, on 10/12/2007, -0/+2Normalization is a great tool. Any idiot can draw up an ERD. But it takes someone who knows what they're doing to validate their ERD using normalization. Sure you can get by without normalization, but you'll probably fall victim to data anomalies that you didn't see before. And what good is your database if it ***** up your data set?
Populating the tables by hand is a good way to ferret out design blunders too. But it takes more time and concentration. Normalization is at least quick and general. - SanityInAnarchy, on 10/12/2007, -0/+2It's actually scary how easy most database stuff is. I doubt it takes much to become a real database expert.
- Mambo, on 10/12/2007, -1/+3How did you go from normalizing database's to the media and then to Microsoft?
- inactive, on 10/12/2007, -0/+2This is common of the vast majority of Americanized words. Though much of the motivation was poliitical, a lot of it was to make the spellings better fit common pronounciation and to keep letter sounds coherent. We have Noah Webster to thank for much of these revised spellings.
- zielgruppe, on 10/12/2007, -0/+2You're right. Normalisation is actually not at all about increasing speed (although most of the comments here go into this direction). The only goal is to avoid redundancy and the resulting inconsistencies. In fact, too much normalisation leads to performance decrease... that's why people start to denormalise again.
- coding, on 10/12/2007, -0/+2Use them. They provide a database supported layer of consistency. This is better than application level consistency just in case your app breaks, or newer and more apps start to use the same tables. The database can guarantee this for you. Finding out your software has bugs during development time is better than losing comments because of some racecondition or something.
Not to mention all of the other awesome things you get from FK mappings: Cascading, Restriction, Nullifying. All these are good because if you design your application around them, you know exactly what code you need to write for say, deleting a forum. The result is based on the database's FK settings rather than in disparate pieces of code in your application(s). - Saba, on 10/12/2007, -0/+1you only end up with "inaccurate, slow, and inefficient" data if you normalise badly. Do it right and your data is more likely to stay correct and efficient for longer.
- TizzyD, on 10/12/2007, -0/+1Normalization is not the performance panacea. Just as a point, I was once brought into a situation where the database was normalized (3rd normal) and a simple query took 45 seconds. Not underpowered hardware, Oracle 8, good stuff all around, but the design did not work. When I looked at the queries used, the developers used pl_sql functions to humanize the results returned. Preprocessing those functions, and then using the table as a cached data set, query times dropped to under a second. There are big differences between knowledge databases and transaction databases, and good designers know what's good when.
- ultrafez, on 02/05/2009, -0/+1Oh ho! We have a smart-ass here just wanting to tell everyone he has learned about quantum physics.
- inactive, on 10/12/2007, -0/+1i'd like to say not to go too nuts with normalization.
it won't kill you to store the end results of somethings, indeed you often have to. eg. quotes/invoices.
i've seen people go so crazy with normalization as to forget that prices and change and you really should store those invoices complete details.
however digg for this articles sound concepts. - carguy84, on 10/12/2007, -16/+17In Russia, database normalizes you.
- inactive, on 10/12/2007, -1/+2DELETE FROM articles.digg WHERE title ~* 'ajax';
UPDATE articles.digg SET diggs = diggs 900 WHERE submitter='seumas';
Stupid digg won't show plus signs :( - xaxxon, on 10/12/2007, -1/+2I'd like to point out that WITH normalisation, database systems can be inaccurate, slow, and inefficient and they might not produce the data you expect.
I'm not saying its a bad thing, just that it's no panacea for all database problems. - duniyadnd, on 10/12/2007, -0/+1I don't know if I can agree with all the points the author put up. At times it is important that you can build tables that are redundant, just for faster queries, especially when you know that those sets of queries would be used very frequently on your website. Similar to caching, but in a table (though you can cache onto a static file but there's only so much you can do with that). Of course in the examples shown, the redundant data makes no sense whatsoever, but if you have to solve summations and averages after pulling in data from multiple tables, and you know that information won't be changing at least once a day, it pays to cache it somewhere else for quicker access.
- curmudgeon7205, on 10/12/2007, -0/+1Normaliz(s)ation presumes that the designer thoroughly knows the data and the business domain. Otherwise, decisions made during the process are made on implied meanings of the metadata (table names, column names, etc.)
I have seen many technically normalized data designs that were flat-out inaccurate because they were created using erroneous assumptions about the meaning of certain data elements. - newfoundnoise82, on 10/12/2007, -1/+2this story brings back the stuff i learned in my database design class.
- ozguralaz, on 10/12/2007, -6/+6It's great article from start to end with examples
- i440, on 10/12/2007, -0/+0I am a novice programmer writing a web application. I have one table for posts, and another for comments. For both comments and posts, I have unique IDs for each. Also, for comments, I have a row called 'postID' that is identical to the ID of the post commented on. However, I didn't define it as a Foreign Key (I just found out about them). Currently, I simply use PHP to get the ID of the post and design queries to retrieve that data (for example, displaying all comments of a post, automatically deleting all comments of a post when a post is deleted, etc.) Should I begin to use foreign keys, and if so, what would be the benefits of using them?
- DCstewieG, on 10/12/2007, -1/+1Yeah that's why DBAs make crap $$$
- SanityInAnarchy, on 10/12/2007, -3/+2On the other hand, I saw a LOT of fancy language there that was confusing... and normalisation isn't really that complicated.
Each time, I went "Ok, that's normalising, but I still don't get why 2n is different than 3n."
And yet, I could've done all of that, certainly with such a simple example. My boss needed me to do some simple MySQL work, and I had only a basic idea of database design, no real experience. By "a basic idea", I mean, I'd seen a tutorial on Webmonkey years ago. He taught me SQL in less than half an hour.
Basically, the reason database people get paid so much seems to be that database people have jargon that confuses the hell out of everyone else for no real reason. Seems the jargon could use a bit of "normalisation" itself -- normalisation is all about proper abstraction, after all.
In reality, most of the time, normalisation is the easiest thing in the world. I imagine what makes one DB designer better than another has more to do with de-normalisation, or noticing from the beginning what should be normalised, and what shouldn't. Someone made a comment about how they could speed up a database by 95% by doing one quick de-normalisation -- that's what takes real skill.
Any monkey can normalise, though, and I suspect that most database people get paid way too much for something that's actually incredibly easy, and that if everyone realized how easy it was, it might become like working at McDonalds or scrubbing toilets -- somebody's got to do it, maybe you even enjoy it, but you can pay less than minimum wage for it, beacuse any monkey could do it. - phenolholic, on 10/12/2007, -1/+0You could always normalize it by integrating over all the variables [fields] of the database and setting it equal to 1. No wait, that's quantum physics.
- ceeam, on 10/12/2007, -7/+5What TF "Mod" field does in "Users" table? You're having problems w/ normalization there, dude. Oh, and that should be "User" table.
- jmbillings, on 10/12/2007, -13/+11There are other countries besides America you know...
- hello2usir, on 10/12/2007, -7/+3Considering that it's not pronounced "nor-mal-ice", I think the Americanization is an improvement.
- inactive, on 10/12/2007, -7/+2normalization is for sissies
Cal Henderson - Zhay, on 10/12/2007, -6/+2I never said there weren't inefficiently designed databases. I merely said that those that design inefficient databases are stupid and shouldn't read about normalization.
- moondog, on 10/12/2007, -7/+2This sounds so exciting....databases....woowee!
- Zhay, on 10/12/2007, -13/+6Half of the stuff on there I did naturally without reading any articles. You would have to be plain stupid to do it inefficiently. Also, the article was poorly written. Then only thing that helped me understand fully what the author was saying was the examples.
- NomenNescio, on 10/12/2007, -15/+6I NEEDED THIS! THANK YOU VERY VERY MUCH!
-
Show 51 - 55 of 55 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is