Step 1: Choose the kind of database you will use

Home

•

Articles

•

BDE Alternatives Guide

•

Services & Training

•

About

Step 1: Choose the kind of database you will use

Database access methods can be broken down in to several categories. In order to discuss the choice of a BDE alternative, it is important to first choose the right kind of database for your application:

Local: the data is on the same computer as the program (and the person using it).

Multi-user File Server: the data is on a file server (Novell, NT, etc.); all processing occurs on the clients, which essentially treat the server as a shared hard drive on a long wire. The requests transmitted between the user computer and the file server are very low-level: "open file X", "read 100 bytes", etc. File-server databases are inherently prone to corruption: if any user computer for any reason cannot complete a database update, the database can be left in an inconsistent state, which will require that all users exit the database application for repairs. Therefore, I recommend file server databases only if:

1) The application is not vital to minute-by-minute company operations, and

2) Security is not vital, and

3) There are less than about 15 users, and

4) There is a good reason not to choose a client/server solution; for example, if the project cannot afford a client/server database (they generally cost more than file server databases)

It is worth noting that in some situations well beyond these limit file server system work quite well. For example, if users do mostly lookups on indexed fields and little data updating, and are on a fast local network, file server based databases can scale to hundreds of users.

Multi-user Client / Server: the clients (users' computers) send high level requests to the server: "find all products with a price < $100". Therefore, more of the processing occurs on the server and less data needs to be transmitted to the clients. The clients never have direct access to the database files and therefore are not able to corrupt them. A Client/Server architecture offer greatly improved resistance to file corruption, and better performance with a large number of users. Therefore, I recommend client/server databases if:

1) The application is vital to minute-by-minute company operations, OR

2) Security is important, OR

3) There are more than about 15 users, OR

4) Any of items 1-3 might become true in the future.

Web-based: for widely distributed data access, web-based solutions offer great scalability and easy deployment; unfortunately this site does not cover this increasingly important topic in depth. Suffice it to say that if you are developing a web-based application, you should choose a database and database access software which is well-suited to a multithreaded environment in which many transaction are occurring simultaneously.

Multi-tier: one or more "third tier" application server sits in between the client software and database backend(s). This addresses scalability problems and deployment burdens in traditional Client/Server database system. Borland's MIDAS is an example of a multi-tier system.

The point here is that first you should choose the database, then choose the BDE alternative to access it. To use an automotive metaphor, choosing truck vs. car is more important than Ford vs. Chevy.

For large, line-of-business applications, my inclination is towards a database server for storage, and middleware (ODBC, ADO, or the BDE) for data access. Middleware is a generalized layer between your app and the underlying database. The benefit of this is that it makes changing database later relatively easy. Data access solutions specific to one database system makes such a change nearly impossible. If you need something that ODBC/ADO/BDE can't deliver (maximum possible speed, single-EXE deployment, etc., then a native solution is appropriate.

Middleware-based solutions include ADO, ODBC, and the BDE.

Proceed to: Step 2: Choose the database format / server