Distributing the Workload

You will get maximum performance from your client-server applications (1) when you store data on the optimum platform (client vs. server) and (2) when you allocate data processing optimally between the client (local machine) and the server. VPM Enterprise provides unique capabilities for distributing the workload between the client and the server.

Data Location

VPM Enterprise gives you complete flexibility in choosing where data should be located to optimize performance. With VPM Enterprise any table can be located on the client or server even the VPM Enterprise system tables.

Application data that all users must access is, of course, always located on the server. System tables that support the basic functionality of a VPM Enterprise application are another matter.

Location of System Tables

Every system table that VPM Enterprise includes in an application can be placed on the client or the server. This capability gives you the flexibility to determine a system data location mix that optimizes performance for the environment in which your applications will run.

When you move the VPM Enterprise system tables to a server database (such as, SQL Server), they enjoy all the benefits of a robust server database.

You can choose whether system tables are located on the client or server because local views are used to implement all VPM Enterprise forms and all functionality that involve the system tables. To use system tables located on the server, all you have to do is:

       Create remote tables on the server that match the local tables.

       Create remote views that match the local views.

       Turn on the remote views on the Edit-Properties and Utilities page of the Data Builder.

Tip: Local views based on the system tables are contained in a VPM Enterprise application's SDATA_V and SVPM_V databases. Do not add your own views to those databases. When we update VPM Enterprise, we may need to make changes to the system views. If so, the VPM Enterprise update would include a new version of the system view databases. The new databases would replace the old version that contained your views, which means that you would lose any views you added to the system view databases.

Whether to locate system tables on the client or on the server is up to you based on whatever considerations are relevant to the operation of your client-server application. Some examples of when you might want to locate system tables on the server include:

       System tables located on a client computer can only be accessed and updated by the user of that client computer. If changes to a system table need to be shared by all users, the system table is a good candidate for the server.

       The VPM Enterprise data dictionary tables normally should be located on the server so that any changes made to database, table, view and field properties are available to all users.

       The audit trail table might be a good candidate for the server if data entry needs to be checked and audited centrally.

       Security system tables might be good candidates for the server if the administration of security is centralized.

       Any system table that needs the benefits of a stable, secure server database might be a good candidate for the server.

Tip: If the purpose of putting a system table on the server is solely to make changes to the table available to all users, there is an alternative approach that may be simpler in some cases than putting the table on the server. The alternative approach is to simply put the local Visual FoxPro system table on a LAN file server that is accessible to all users. This approach does, of course, require all users to have access to the file server over a LAN.

Data Integrity Processing Location

One of the benefits of using a robust database server like MS SQL Server or Oracle is the server's sophisticated handling of entity, domain and referential data integrity.  However, when you use VPM Enterprise to build a client front-end to a database server, you have at your disposal the sophisticated handling of entity, domain and referential data integrity built into VPM Enterprise. In fact, the data integrity capability of VPM Enterprise surpasses the data integrity capability of most database servers.

What this means for you is that with VPM Enterprise, you can choose to let the VPM Enterprise front-end enforce data integrity on the client before the data is passed to the database server. VPM Enterprise's data-related functionality can be used on the client to minimize the workload placed on the server.

Letting VPM Enterprise handle data integrity processing provides the following benefits:

       Improve Server Performance: It takes the load off the server. For example, letting the VPM Enterprise front-end application process referential integrity for updates and deletes takes the load off the server. That might contribute significantly to server performance in a client-server environment involving heavy data maintenance by many users.

       Provide Functionality the Server Doesn't Have: It can provide data integrity functionality that the database server does not provide. For example, if the server database you are using doesn't provide extensive data integrity capability (e.g., MYSQL), your VPM Enterprise application will come to the rescue.

       Easier Setup: You can shortcut the set up of data integrity on the server by using the VPM Enterprise data integrity functionality for, say, referential integrity instead of the corresponding server integrity.  It may turn out in some cases to be easier to set up and maintain data integrity in VPM Enterprise than in the database server.

       User Setup of Data Validation: VPM Enterprise is particularly good at data validation. Through the Data Manager users can even set up their own data validation rules. If user access to data validation set up is important, using the VPM Enterprise data validation functionality may be preferable to using whatever data validation functionality is provided by the database server.

Tip: Up to this point our discussion of where data integrity processing is located has focused on using VPM Enterprise's functionality in lieu of the database server. There may be some situations in which you only want to use the database server's data integrity processing. In those cases, you can turn off data integrity processing on the VPM Enterprise front-end.


Performance Considerations