fovorti.blogg.se - As well as simply being too many.

That’s when the “hacking” starts, with the veiled promise to go back and fix things later, something that happens very rarely indeed.Īdmittedly it is impossible to predict every need that your design will have to fulfill and every issue that is likely to arise, but it is important to mitigate against potential problems as much as possible, by careful planning. The project heads off in a certain direction and when problems inevitably arise – due to the lack of proper designing and planning – there is “no time” to go back and fix them properly, using proper techniques. Furthermore, if you don’t take the time at the start to get the database design right, then you’ll find that any substantial changes in the database structures that you need to make further down the line could have a huge impact on the whole project, and greatly increase the likelihood of the project timeline slipping.įar too often, a proper planning phase is ignored in favor of just “getting it done”. Since the database is the cornerstone of pretty much every business project, if you don’t take the time to map out the needs of the project and how the database is going to meet them, then the chances are that the whole project will veer off course and lose direction. Like a house, a good database is built with forethought, and with proper care and attention given to the needs of the data that will inhabit it it cannot be tossed together in some sort of reverse implosion. If you answered yes, I am not sure if anything I can say will help you. A design is needed make sure that the house you want gets built, and that the land you are building it on will not sink into some underground cavern. Let me ask you: would you hire a contractor to build a house and then demand that they start pouring a foundation the very next day? Even worse, would you demand that it be done without blueprints or house plans? Hopefully, you answered “no” to both of these. Prophetic words for all parts of life and a description of the type of issues that plague many projects these days. “ If you don’t know where you are going, any road will take you there” – George Harrison

Not using stored procedures to access data.

Not using SQL facilities to protect data integrity.

Using identity/guid columns as your only key.

Hopefully, after reading this article, the little voice in your head will talk to you when you start to stray from what is right in terms of database design practices. When I speak, or when I write an article, I have to listen to that tiny little voice in my head that helps filter out my own bad habits, to make sure that I am teaching only the best practices.

I used to have a preacher who made sure to tell us before some sermons that he was preaching to himself as much as he was to the congregation.

And these aren’t exactly the same ten that I started with these are ten that stand out to me as of today.īefore I start with the list, let me be honest for a minute. Originally there were ten, then six, and today back to ten. I also presented a boiled down, ten-minute version at PASS for the Simple-Talk booth.

If you’re interested in hearing the podcast version, visit Greg Low’s super-excellent SQL Down Under. People (myself included) do a lot of really stupid things, at times, in the name of “getting it done.” This list simply reflects the database design mistakes that are currently on my mind, or in some cases, constantly on my mind. No list of mistakes is ever going to be exhaustive.

Ten Common Database Design Mistakes - Simple Talk Skip to content