SQL For Dummies®

Chapter 21. Ten Common Mistakes

In This Chapter

• Assuming that your clients know what they need

• Not worrying about project scope

• Considering only technical factors

• Never asking for user feedback

• Only using your favorite development environment or system architecture

• Designing database tables in isolation

• Skipping design reviews, beta testing, and documentation

If you're reading this book, you must be interested in building relational database systems. Let's face it — nobody studies SQL for the fun of it. You use SQL to build database applications, but before you can build one, you need a database. Unfortunately, many projects go awry before the first line of the application is coded. If you don't get the database definition right, your application is doomed — no matter how well you write it. Here are ten common database‐creation mistakes that you should be on the lookout for.

Assuming That Your Clients Know What They Need

Generally, clients call you in to design a database system when they have a problem getting the data they need because their current methods aren't working. Clients often believe that they have identified the problem and its solution. They figure that all they need to do is tell you what to do.

Giving clients exactly what they ask for is usually a sure‐fire prescription for disaster. Most users (and their managers) don't possess the knowledge or skills necessary to accurately identify the problem, so they have little chance of determining the best solution.

Your job is to tactfully ...