ch11lev1sec8

   

Performance Optimizations

The ADO components offer a variety of potential performance trade-offs. Obviously, the success of these optimizations will depend on the nature of your database, such as whether it is a client/server database or a local desktop database. Therefore, you are encouraged to try to understand the performance implications of the various component properties; even those not discussed here.

Query or Table

For client/server work, a query that will be executed on the server is preferable to a table because a table-based component will typically transfer all the records from the database server to the client system, consuming network bandwidth and taking extra time. This is especially important when you intend to filter the records, because a query can have the server apply the filter before the records are sent to the client.

Cursor Location

A cursor is basically the current state of the dataset ”which record is current, the means by which insertions and deletions are performed, and so on.

The ADO components enable you to have a cursor on the client- or the server-side. A client-side cursor can initially be more expensive than a server-side cursor, but if the data set is relatively unchanging, it can be a setting that offers greater throughput in the long run. It will upload a copy of the selected data once to the client machine, and all subsequent operations are performed on that local copy, but then reflected back to the server. In this sense, it is much like the BDE ClientDataSet , except that no special management is required. However, critical to making client-side cursors perform well on inserts and updates is setting MarshalOptions to moMarshalModified Only . The other setting, moMarshalAll , will transmit the entire client-side copy of the data to the server on any change.

But a server-side cursor can be more efficient for a large dynamic dataset, especially when you typically need only a small part of the data on the client side. Although a thousand-row table might be suitable for a client-side cursor, a million-row table is much more likely to perform well with a server-side cursor.

Note that a server-side cursor is more likely to be unidirectional (forward only) than a client-side cursor according to the documentation.

Cursor Types

Cursors can also operate with different restrictions that have performance implications. The performance of various cursor types are described in the following list.

  • A ctOpenForwardOnly cursor is very fast because it does not require the extra overhead (whatever that may be, depending on the DBMS) that would enable it to seek backward to an earlier portion of the dataset. Such a cursor must always start from the beginning and move forward. Note that such a cursor is read-only.

  • A ctStatic cursor is nearly as fast, but it allows forward and backward movement. Like the forward-only cursor, it is read-only and is isolated from changes made by other users.

  • A ctKeyset cursor is a read/write, any position, any direction cursor that remains isolated from changes by other users.

  • A ctDynamic cursor adds the capability to see changes from other users.

Buffering

The CacheSize property controls how many records are cached locally. A larger cache can mean better performance, as long as you stay within the bounds of the cached records. But the larger the cache, the more expensive random movement or sequential traversal of the dataset might be because the cache must be refreshed with the new region of the dataset. In addition, this is affected by the choice you make for the location of the cursor. A larger buffer is probably more critical for a server-side cursor than for a client-side cursor because the client-side cursor typically has the entire data set locally anyway.


   
Top


C++ Builder Developers Guide
C++Builder 5 Developers Guide
ISBN: 0672319721
EAN: 2147483647
Year: 2002
Pages: 253

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net