Timeline for Most regrettable design or programming decision you made?
Current License: CC BY-SA 2.5
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 4, 2011 at 21:29 | comment | added | deadalnix | Oh god ! I have bunch of problem in a current project because the previous lead was doing such a mistake. First do the data structure normalized. Second, benchmark, and see what could be changed to improve that. Thirs do the modification on the DB, encapsulate that into your model so it looks perfectly normalized for everything else in the application. Do not, NEVER, begin with step 3 unless you want to end up with really messy code. | |
| Jun 4, 2011 at 21:24 | history | made wiki | Post Made Community Wiki by Bobby Tables | ||
| Oct 6, 2009 at 17:59 | comment | added | Eimantas | I'm pretty confident I normalized enough to write this answer .) | |
| Oct 6, 2009 at 15:30 | comment | added | çağdaş | You probably didn't normalize enough. | |
| Sep 28, 2009 at 13:58 | comment | added | Eimantas | Probably, but creating data structures is only the process in the beginning and using/maintaining those data structures takes most (read: almost all) of the time, hence usually denormalization comes only by demand. | |
| Sep 28, 2009 at 12:53 | comment | added | Keith Williams | But normalisation is FUN! :) I'm serious, I enjoy designing data structures. What I would say is that whilst it's easy to de-normalise a normalised schema, the reverse is NOT true. You need to KNOW the rules before you break 'em. | |
| Sep 24, 2009 at 17:24 | comment | added | Eimantas | My approach to normalization is always straight-forward. I always normalize, BUT if i see a potential performance boost on little flattening - i always test and benchmark and in most cases it pays of to flatten. | |
| Sep 24, 2009 at 16:02 | comment | added | Jay | I think programmers are too quick to denormalize for inadequate reasons, but yes, slavish adherence to the rules of normalization is a big mistake. In general, one of my great frustrations in software development is when someone says "We must do X", and when I point out all the problems this will cause, they reply, "That's irrelevant. All the experts agree that X is good, therefore we must do X, always, no exceptions." | |
| Sep 24, 2009 at 14:58 | comment | added | David Thornley | Normalization (within limits) is great for putting stuff into a database, but slow for getting things out. Get your transaction processing database reasonably normalize, and denormalize your data warehouse. | |
| Sep 24, 2009 at 14:58 | comment | added | syaz | A related blog post by Jeff titled Maybe Normalizing Isn't Normal: codinghorror.com/blog/archives/001152.html | |
| Sep 24, 2009 at 14:54 | comment | added | Alex Marshall | I fully agree with napster above, over-normalization really bit me in a major project for our company | |
| Sep 24, 2009 at 14:49 | comment | added | The real napster | I might add that normalization also can be very positive of course. | |
| Sep 24, 2009 at 14:48 | comment | added | The real napster | I could not agree more... I am a software engineer and we are told to always normalize. What a crock of shit. It was only because the teachers havent tried working with truely complex and performance dependent DB's. | |
| Sep 24, 2009 at 14:28 | history | answered | Eimantas | CC BY-SA 2.5 |