A ten-step guide to guerrilla database management. (Compute's Getting Started With: Databases)
by Tom Campbell
There are two ways to get things done in life: the way you're supposed to and the way that actually gets things done. This is a ten-step guide to database management for the guerrilla user--someone who just wants to get the job done and get out with a minimum of fuss.
1. Play, and change your mind a lot.
The books tell you to plan your database and file schema on graph paper, pray to the relational gods, and sacrifice virgins when necessary. The thought is that you don't want to commit the unforgivavble crime of bad planning, because it will cost you in productivity for at least the next hundred years. Don't be ridiculous. Today's DBMSs are so flexible and so easy to design and redesign that you should make it your highest priority to play with them and try out neat stuff. Sure, you'll make mistakes. But you won't feel locked into stale ideas.
2. Don't duplicate data.
You should never duplicate data. For once, the experts are right. If you have any application in which a customer's name or address needs to be typed in more than once, for example, you have a problem. In general, you should never type in anything more than once. If the information has been typed in once, it should appear in a lockup field. Duplicate data means that someday you'll forget that you have that data in two places, and you'll lose customers. You should only have to type in information a second time when you're looking something up.
3. Use a new table anytime you need one.
Some books still promote bad database design because of DOS's open file limitations or early DBMS designs. They would use a single table where multiple tables make more sense. Under Windows and any DOS DBMS worth its salt, open file limitations are irrelevant.
4. Never sort; always index.
Early DBMSs had a sort command that would change the physical location of records. Sorting should be handled by indexes, never by physical reordering of data. Sorting is incredibly slow, and any indexing scheme that relies on physical record placement is flawed.
5. Make sure the DBMS lets you change the table layout.
A few DBMSs don't let you change the design of a table once you've created it--that is, you can't change the names of fields, and fields, or remove them. Make sure you can change your mind about tables at any time.
6. If you hire a consultant, get second and third opinions.
I've seen many database applications created by consultants, and I'm usually shocked at how bad they are. Don't hire a consultant unless you have a money-back guarantee, you've already used one of his or her applications extensively, or you have a ringing endorsement from someone you'd trust with your life.
7. Compatibility with dBASE is overrated.
I used to be bullish on dBASE file compatibility. My theory was that if your application couldn't at least export dBASE data files, you were headed for trouble if the company tha created your application went under. Nowadays, compatibility means any number of things, but you still need to be sure there's some way to get the data out of any database application you use in case the company that created it goes belly up.
8. OLE!
As a bleeding-edge programmer, I shouldn't admit this, but it was a year before I tried OLE. It's childishly simple to use, and you owe it to yourself to read the OLE chapter of your database spreadsheet, or word processor programs that support it. OLE will change your life, give you healthier teeth, and make you more popular with the in crowd. Well, maybe not--but break with tradition and read the documentation for once.
9. Use the Clipboard
I discuss using the Windows Clipboard elsewhere in this section. While you should never use it for routine data transfer (that's what OLE is for), you'll save a ton of time if you spend the half-hour it will take to master the Clipboard. It will save typing time a data entry errors for as long as you use a GUI environment such as Windows or the Mac's.
10. Ignore these rules and make up your own.
The truth is that not even the experts know what they're doing all the time. This field is much too young for anyone to be sure about the best ways to create forms or manage data.
Try to keep an open mind, but also be willing to accept an approach that works even if it hasn't been sanctified by the higher-ups. Sometimes, the end does justify the means.