Designed to Help You Run Your Business More Efficiently.
	Home  |  About AIMS  |  Contact Us

• Clients   • FAQs   • Programs   • Tips   • Fees

FREQUENTLY ASKED QUESTIONS Why do I need a database? What are the drawbacks? What about an off-the-shelf program? Why can't I design my own database? What are these 'Field Rules' you talk about? How long will it take? Why do I need a database? Many people start their database with a spreadsheet but, as the database becomes larger and more complex, the spreadsheet becomes more and more difficult to work with. There are many advantages to using a database. Here are just a few: A database can contain a virtually unlimited number of records while most spreadsheets have a limited number or rows. Data input can be controlled much better in a database through the use of field rules. This means fewer input errors - especially when new employees or temporary help are involved. Data input can often be easier, faster, and more versatile through the use of lookup lists and lookup tables. Multiple report formats can easily be created for the same data without physically re-sorting or re-arranging any data. Many applications have 50 or more different reports and some number in the hundreds. Reporting capabilities are much more powerful and formats can generally be more complex. Sorting and filtering of data for viewing, editing, and reporting is much easier and more powerful than with a spreadsheet. A well designed database application is easier to use and less error prone than a spreadsheet. This is especially true for new users and temporary help. Top What are the drawbacks? This is also something that many database developers don't like to talk about but there are some drawbacks: Database programs are more complex than spreadsheets so users will find it more difficult to use a 'raw' database program than to use a 'raw' spreadsheet program like Excel. This is the reason for building database applications. As mentioned above, a well designed database application is easier to use, and less error prone, than a spreadsheet because all the controls have been built in. A professionally designed database application is often fairly expensive. Very few custom applications will cost less than $2000. However, the time savings and efficiencies provided by a well written application often result in a payback of less than a year. In addition, it is not unusual for a database to produce information that was never previously available thus resulting in additional savings. Unfortunately, it is often difficult or impossible to identify where these time savings, efficiencies, and new data will come from until after the application has been nearly completed. Most databases are computer resource hogs. Compared to word processors and spreadsheets, any good database program will require a better computer in order to run efficiently. Databases also put more load on networks than almost any other type of program. This can be an issue for companies with older computer systems. Top What about an off-the-shelf program? There are a lot of off-the-shelve database applications available. Any accounting program, tax program, etc. - and there are many others - is basically a database application. These programs are relatively inexpensive compared to the actual development cost due to the large number of people who purchase them but they are also fairly rigid in that they have been designed to work with fairly 'standard' processes. If these programs meet your needs, use them. The reason some companies decide to have a custom database built is that the off-the-shelve applications are not flexible enough to work they way their company works. Many of those companies started with an off-the-shelf program but later found it to be too limiting. They either decided it would be better to create a custom application than to change their internal procedures or they found they needed additional functionality that would not be available otherwise. Another factor is that most off-the-shelve applications must be designed to include only those features needed most often. It is not cost effective for them to include features that would only be used by a few customers. A custom database application doesn't have this restriction so each application can be designed to work exactly the way your company works. Many companies consider their custom database to be a part of their competitive edge over the competition. Top Why can't I design my own database? You probably can. And, even if you are not a surgeon you could probably operate on a brain tumor - but it takes a lot of training and practice to learn to do it without killing the patient. Now, databases aren't nearly as complex as operating on brain tumors and the consequences certainly aren't as serious. However, using a database effectively is orders of magnitude more complex than what most people do with a spreadsheet. Even those who know how to write macros for spreadsheets will find that building a good database application is still far more complex. Even if you have the time and inclination to read all the instructions and learn how to use the database program, there are a number of other aspects to building a good database application that only come through training and practice. A good database developer knows how to properly organize the data to get the desired outputs, maximize accuracy of input data, and maintain flexibility for future updates. A good developer will also have created shortcuts for common situations and may know methods that will allow him to do something in minutes that might take you hours or days to figure out. In addition, a good developer will often see potential improvements that you might never have considered. Sometimes it's these additional improvements that make the biggest contribution to the efficiency of the finished application. So, the bottom line is that you could probably do it yourself but you need to evaluate the cost savings versus the additional time required and the possible missed opportunities. Top What are these 'Field Rules' you talk about? "Field Rules" is a catch-all phrase used to include all the procedures created to control data input. Field rules cover things like: Capitalization. Required fields. Auto-incremented values. Default values. Unique field value requirements. (Part number must be a unique number.) Field validations. (A number must be between 1 and 100, or a date must be before today.) Lookup values and fill-ins. (From simple lists, cascading lists, or other data tables) Posting. (An item sold could be posted to the inventory table to remove it from the total on-hand.) In addition, almost any custom field rule imaginable can be created by the developer to handle special requirements. Top How long will it take? This may be the toughest question of all. There are so many factors that go into estimating the time required to build a custom application that coming within 20% of the correct number of actual hours spent is usually considered to be an excellent estimate. Add to this the other issues that can delay development time and it becomes even more difficult to determine a completion date. It is very difficult, and usually inefficient, for a programmer to spend a full 8 hours working on one program so a program that is estimated to take 40 hours will probably take at least two weeks if everything else goes perfectly. Add to that the delays that can result while questions are being sent back and forth, the delays to fix bad data, the delays that can result from a mis-understanding of the exact program requirements, interruptions for phone calls, emergency issues with other projects, etc. and the result can be a 40 hour project that takes a month to complete. It's probably fair to say that few applications will be completed in 2 weeks or less and some may take 6 months or more depending on their size, complexity, and scope. As a percentage of overall time, the delays encountered while developing a small application are generally much greater than the delays in a large project. Top

AIMS DataCom, Inc. - Custom Database Applications This site created and maintained by Cal Locklin, CALocklin@chartermi.net, using 1st Page 2000.   Last update:  15-Apr-03 This site may be freely linked to but not duplicated in any fashion without prior written consent.