EPM will funnel all database access through data access layer components. These Component Object Model (COM) components offer several benefits:

It concentrates all ADO code in a single place. This makes it easy to modify the ADO related code for best performance.

If we decide to use SQL Server as database store then our data access tier maps SQL Server stored procedures to a set of easy-to-use, familiar functions.

If in future we want to port EPM to another database, like Oracle 8, we only need to port this component.

Our best performance gains came from a finely tuned data access layer. In addition to this, having a single point of data access in application will make it easy to tackle all the database related bugs. The design pattern for the business tier is similar to that used by the data access layer code with only difference of missing code for accessing a database in business logic layer. Business logic layer will be just a consumer of recordsets produced by this layer.

Separate data access layer will create more maintainable code but will also far more extensible and reusable code. Moving data access code to different layer will remove redundant code and thus reduce the size of code.

This separation of data access from the applications will also give us more flexibility in the distribution of the application.

During the phase of moving database to SQL Server we will move code database activities to the stored procedures. Which will boost the performance of the application.