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.
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 convince your client that you are an expert in systems analysis and design, and that you must do a proper analysis to uncover the real cause of the problem. Usually the real cause of the problem is hidden behind the more obvious symptoms.
Your client tells you what he or she expects from the ...