Limiting Direct Access to

Data"> As database programming capabilities become more powerful and accessible, enterprise database developers increasingly have the option of limiting applications direct access to raw data—viewing it only through the filter of a business rule. For example, an application might execute a database-level procedure that performs a test and returns the result to the application, such as a true/false value for "Customer has sufficient available credit," instead of the application requesting and being given the customers current available credit amount and making the determination itself.

In this way, the database designer can devise and enforce policies on information access rather than leaving those policies to be communicated to, understood by and correctly implemented in the code of many different application developers.

New regulatory and legislative mandates are ratcheting up the penalties for handling data improperly, but this should not unduly tip the scales in the direction of deciding not to handle it at all. To avoid making a business failure out of a technical success, database developers should take part in business unit discussions of risk and reward.

Responding to pressures such as Californias SB 1386 legislation, which mandates public notice of a database security breach, developers might rationally define their database design and operational boundaries on grounds of simply minimizing risk—presenting the resulting decisions as fait accomplis to business units. Development teams should resist this temptation, though, and should instead elevate their participation in higher-level discussions of database and application missions.

Speed and maneuverability

Every extension of database technology into new applications domains increases the demand for speed—not merely average performance but, increasingly, a guaranteed worst-case performance in real-time and services environments.

Developers may be tempted to satisfy the clamor of speed demons by unleashing other demons—specifically, by relaxing security standards. Vendors such as DataMirror Corp., for example, are attempting to resolve that conflict by using increasingly affordable in-memory technologies to demolish key performance barriers without security compromises.

DataMirrors PointBase 5.1, last months update to that pure-Java (and therefore highly mobile) database platform, incorporates such refinements as memory-based hash joins to address application bottlenecks. It also provides data compression for TCP/IP transfers to improve synchronization performance on intermittent and/or limited-bandwidth connections, which are especially likely to be encountered with expanding database services to remote users.

Data compression is only part of an overall strategy that database developers should apply to minimize the need for continuous or prolonged connection when designing remote-user applications.

Distributed user populations are very much the target of another database technology vendor, Adesso, of Boston. Adessos chairman and chief technology officer, John Landry, spoke with eWEEK Labs for this report. "The most untapped return on investment on the planet is in the field," Landry said. "Theres enormous opportunity for productivity enhancement and knowledge enhancement, where right now theres at best e-mail and spreadsheets and at worst still paper-based procedures."

What has held back the broader use of databases in the field, Landry said, is a combination of too little connectivity and too much database heterogeneity. He said that even if a development team can stick to a single database vendor such as Microsoft Corp.—as Adesso has, so far—the enterprise database, laptop computers and handheld devices will still be using different database products that present different faces to the developer.

Next Page: Building Platform Versatility