Designing Dynamic Databases PDF Print E-mail

Six Tips To Keep Your Sanity:

1. Outline your design requirements before looking at any solutions. If you or your team "imprint" with a software tool, you'll sabotage your own effort to find the best solution.

2. Once your priorities are determined, circulate this list to interested parties for buy-in, especially the authorities who will approve any purchase.

3. If possible, create a data sample from your own system. Ask sales people to install your data on their system and try out the system with your own data. No matter what the salesperson claims, this is usually where I find out what the software can and cannot do. Check to see if the data was massaged.

4. Start looking at products to get ideas of what you might be able to do. Don't restrict yourself to solutions designed exclusively for your application. For instance, I usually use library software to manage large resume databases (over 500). That's because we need very sophisticated text search capabilities not found in "proposal management" software tools.

5. Avoid "cul-de-sac" software. This is a killer. You pay to install your data in a software solution, only to find later that you cannot export the data to another system because it is corrupted with code. (c)2005 Laura Ricci

6. Design for "elasticity." How many different ways might you be able to use the system? Can other departments' requirements be met? They may share the cost and maintenance burden if you can meet their requirements. How many ways can you migrate data to another system? The more, the better.

7. All knowledge is kept by people. Data does not magically populate a database, someone must volunteer it. Most database installations fail for want of buy-in from the keepers of the data. You can mitigate this issue by designing "give and take" into your system.
 

Ricci Legacy

The Ricci family has been consulting and supporting success for hundreds of years.

Visit Laura's Blog