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

Using only 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. 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 information 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.

Ignoring Project Scope

Your client tells you what he or she expects from the new application at the beginning of the development project. Unfortunately, the client almost always forgets to tell you something — usually several things. Throughout the job, these new requirements crop up and are tacked onto the project. If you’re being paid on a project basis rather than an hourly basis, this growth in scope can change what was once a profitable project into a loser. Make sure that everything you’re obligated to deliver is specified in writing before you start the project.

Considering Only Technical Factors

Application developers often consider potential projects in terms of their technical feasibility, and they base their time and effort estimates on that determination. However, issues of cost maximums, resource availability, schedule requirements, and organization politics can have a major effect on the project. These issues may turn a project that is technically feasible into a nightmare. Make sure that you understand all relevant nontechnical factors before you start any development project. You may decide that it makes no sense to proceed; you’re better off reaching that conclusion at the beginning of the project than after you have expended considerable effort.

Not Asking for Client Feedback

Your first inclination might be to listen to the managers who hire you. After all, the users themselves don’t have any clout and they sure as heck don’t pay your fee. On the other hand, there may be good reason to ignore the managers, too. They usually don’t have a clue about what the users really need. Wait a minute! Don’t ignore everyone or assume that you know more than a manager or user about what a database should do and how it should work. Data-entry clerks don’t typically have much organizational clout, and many managers have only a dim understanding of some aspects of the work that data-entry clerks do. But isolating yourself from either group is almost certain to result in a system that solves a problem that nobody has. You can learn a lot from managers and from users by asking the right questions.

Always Using Your Favorite Development Environment

You’ve probably spent months or even years becoming proficient in the use of a particular DBMS or application development environment. But your favorite environment — no matter what it is — has strengths and weaknesses. Occasionally, you come across a development task that makes heavy demands in an area where your preferred development environment is weak. So rather than kludge together something that isn’t really the best solution, bite the bullet. You have two options: Either climb the learning curve of a more appropriate tool and then use it, or candidly tell your clients that their job would best be done with a tool that you’re not an expert at using. Then suggest that the client hire someone who can be productive with that tool right away. Professional conduct of this sort garners your clients’ respect. (Unfortunately, if you work for a company rather than for yourself, that conduct may also get you laid off or fired. It’s best to go with option one — dive on into a new development environment.)

Using Your Favorite System Architecture Exclusively

Nobody can be an expert at everything. Database management systems that work in a teleprocessing environment are different than systems that work in client/server, resource sharing, web-based, or distributed database environments. The one or two systems that you are expert in may not be the best for the job at hand. Choose the best architecture anyway, even if it means passing on the job. Not getting the job is better than getting it and producing a system that doesn’t serve the client’s needs.

Designing Database Tables in Isolation

If you incorrectly identify data objects and their relationships to each other, your database tables are likely to introduce errors into the data and destroy the validity of any results. To design a sound database, you must consider the overall organization of the data objects and carefully determine how they relate to each other. Usually, no single right design exists. You must determine what is appropriate, considering your client’s present and projected needs.

Neglecting Design Reviews

Nobody’s perfect. Even the best designer and developer can miss important points that are evident to someone looking at the situation from a different perspective. Presenting your work before a formal design review can actually make you more disciplined in your work — probably helping you avoid numerous problems that you may otherwise have experienced. Have a competent professional review your proposed design before you start development. You should have a database designer check it over, but you may want to show it to the client, as well.

Skipping Beta Testing

Any database application complex enough to be truly useful is also complex enough to contain bugs. Even if you test it in every way you can think of, the application is sure to contain failure modes that you don’t uncover. Beta testing means giving the application to people who don’t know how it was designed. They’re likely to have problems that you never encountered because you know too much about the application. If they’re familiar with the data, but not the database, they’re also more likely to use the application as they would on a daily basis, so they can pinpoint queries that take a long time to generate results. You can then fix the bugs or performance shortfalls that others find before the product goes officially into use.

Not Documenting Your Process

If you think your application is so perfect that it never needs to be looked at, even once more, think again. The only thing you can be absolutely sure of in this world is change. Count on it. Six months from now, you won’t remember why you designed things the way you did, unless you carefully document what you did and why you did it that way. If you transfer to a different department or win the lottery and retire, your replacement has almost no chance of modifying your work to meet new requirements if you didn’t document your design. Without documentation, your replacement may need to scrap the whole thing and start from scratch.

Don’t just document your work adequately — over-document your work. Put in more detail than you think is reasonable. If you come back to this project after six or eight months away from it, you’ll be glad you documented it in detail.