Design flaws can derail your database applications, driving away users and clients. Fortunately, many mistakes are easy to avoid. This ebook covers common design pitfalls and explains the best practices that can prevent them.

From the ebook:

Database developers make mistakes just like everyone else. The problem is, users are the ones who pay for those mistakes when they have to work with slow, clunky applications. If you’re part of your company’s IT team, a mistake could cost you your job. If you’re a freelance developer, a bad database usually means a lost client—and even more lost business, if word gets around.

And the stakes have gone up, too: With so many websites running dynamic pages supported by an underlying database, good development practices have never been more important.

Here are some common design pitfalls to watch out for.

1. The data’s unimportant; it’s the architecture that matters
If you don’t know the data, it doesn’t matter if your code sings. You want the two to work in harmony, and that means spending some time with the people who use and manipulate all that data. This is probably the most important rule: Before you do anything, you absolutely must get intimate with the data. Without that firsthand knowledge, you might make errors in judgment that have far-reaching consequences—like dragging the whole application to a complete halt.

A nonchalant attitude that the data isn’t important isn’t a sign of laziness. It’s a mistaken perception that anything that doesn’t work quite right early on can be fixed later. I just don’t agree. Doing it right from the bottom up will produce a foundation that can grow and accommodate change quickly. Without that foundation, any database is just a few Band-Aids away from disaster.