Overdesign is also very common with databases. People get hung up on rules like “third normal form”. Sometimes when you over-normalize a database is [sic] makes it impossible to query the data later on. If your application is going to require reports, sometimes its better to design the database with the reports in mind. In other words, let the reports dictate how the data is stored.

This kind of advice is insane, ridiculous stuff. Take a minute and read what the third normal form means. Not following the third normal form means essentially having duplicate data in different places in your database creating a serious nightmare in maintaining data integrity. What you gain in reporting, you will lose when you start writing code to ensure that data is consistent everywhere.

Normalizing a database does not make it “impossible” to query data. If you have many tables because of normalization, work is harder because you need multiple joins to do the trick. But if you know elementary SQL, you can get it done easily. On the other hand, if you haven’t normalized properly, you have very silly problems. For example, in the Wikipedia example, to find out how many players were born on the 1st of January, you have to write code that does not count the birthdays of multiple players twice. In a normalized database, it is an extremely simple query.

It is ironic that the author talks about “overdesign” while falling victim to premature optimization. First, understand what normalization is supposed to do and how it helps you. Learn SQL or use tools that can help you get your data out easily. Profile your application and find ways to improve performance. And only if everything fails, then go for denormalization. And that too, only after understanding its downsides and how to prevent them.

Read my previous article on the same subject.

There are several problems with the idea that you would want to change databases in the future. One is that in a non-trivial application, your interaction with the database is not limited to running SQL queries against it. Most mainstream database servers have several features that enable you to gain better performance and scale your application better. And you would be well advised to use such performance tuning.

If you decide to switch to another database server, you will have to do similar activities in the new server. You would have to relearn how to do it in the new server, or hire resources who are knowledgeable in it. There is also the possibility that some data migration efforts may be required, even though tools do exist. It is not as simple as you may think and is more a distraction than a benefit to the project.

In terms of price and scalability, most database vendors also offer you an easy path upwards. You can run the lowest version on your desktop and it probably costs $0. And there would be a high-end version that scales to multiple machines and costs thousands of dollars. So the need to rewrite the software for another database server is reduced.

Now, I have seen instances where a rewrite from Oracle to mySQL (for cost reasons) or from Access to SQL Server (for scalability) or from some dead database vendor’s database to a database in the present market has been done. But these were projects where there was no ORM to begin with. If somebody started a project in recent times and then had to change their database server, I wonder what thinking they put into selecting the database in the first place.

Just as you would not choose your programming technology in a casual manner, it is important to put sufficient effort in choosing the right database server. Being cavalier about it and assuming you can easily shift database servers (and would want to) in the future is not the right way to go.