Desktop Databases Pack More Power

PC database vendors are touting the ability of their products to scale from the desktop to the enterprise. But a closer look at today's PC databases reveals that vendors' definitions of scalability vary widely.

Jane Richter

You're going to hear a lot about database scalability in the coming months. The PC's ever increasing capabilities let vendors deploy powerful database applications on the business desktop. But a close examination of PC databases reveals that definitions of scalability can vary widely.

An early definition of scalability referred to a S calable P rocessor ARC hitecture (the ANSI/SPARC standard) used to implement different technologies with hardware components of potentially many different sources and sizes. To be scalable, a system must have the ability to add or replace components in the system architecture. In today's software market, two complementary forms of scalability exist.

In its first form, scalability refers to the ability of an application to support multiple, concurrent processors. This horizontal scaling allows users to increase processing power without having to change applications, operating systems, or even computers. In this scenario, when you add a CPU, the system transparently handles data location and transaction distribution.

In its second form, scalability is the ability to create an application for potential use on many different computers and platforms. In the strictest sense, this type of scalability, called vertical scaling , refers to the ability to move an application among multiple computing platforms.

Vertical scaling's success requires equivalent database products across all platforms and depends upon the consistency of the languages and APIs between platforms. Only a limited number of products support this type of vertical scaling for the PC user. Ashton Tate, creators of dBase, published equivalent versions of dBase for the DOS, Mac, and Unix platforms (Borland, which acquired Ashton Tate, has yet to do so). Gupta's SQLBase also supports vertical scaling between its DOS, NLM (NetWare loadable module), Windows, NT, SunOS, and OS/2 offerings. Oracle's Workgroup 2000 (Personal Oracle7, Oracle Objects for OLE, and the upcoming Oracle Power Objects) allows applications to run interchangeably between Windows, Mac, and OS/2 versions.

However, many other database vendors define scalability as the ability to use a single application, or front end, to access data and services on multiple computing platforms, or back ends. With front-end scalability, applications designed on a single platform (typically DOS, Windows, or Mac) access data stored on a variety of back-end products and platforms. In addition to consistency between lan guages and APIs, front-end scalability also requires tools to support communication and reliable data transfer between various hardware platforms and software packages.

Many full-featured database products, such as Borland's Paradox and dBase software, Lotus Approach, Microsoft Access, and FoxPro (including the forthcoming Visual FoxPro), allow front-end application development and offer access to data stored on a variety of database servers, including MS SQL Server, Oracle, Sybase, and those offering ODBC (Open Database Connectivity). Microsoft takes Access one step further with an Upsizing Wizard that converts stand-alone database applications to an Access front-end and a Microsoft SQL Server back-end. In addition, a whole genre of products, such as Gupta's SQLWindows and Sybase's PowerBuilder, are designed specifically for scalable front-end development.

To implement front-end scalability, cross-vendor software solutions rely on standards, and standards typically lag behind technology. Both t he SQL Access Group's SQL standard and Microsoft's vendor-neutral ODBC standard make it possible to develop applications using sophisticated database server software while taking advantage of the ease of use and relatively low cost of hardware and software on the personal computer platforms. The problem: To take advantage of nonstandard functionality (which typically includes vendor-specific features and recent innovations), the developer must sacrifice scalability. This is why many vendors refer to ODBC as the least-common-denominator approach. For example, neither the SQL Access Group nor ODBC take advantage of triggers or stored procedures.

Single-vendor front-end development (using front-end and back-end software from the same vendor) guarantees both language and API consistency. Though single-vendor solutions tend to rely on proprietary technologies, which creates a dependency on that vendor, these solutions let developers take full advantage of the vendor's extended feature set.

These homo genous solutions introduce one more exciting prospect for the PC database developer: the possibility of developing truly scalable database applications (not just front ends) on the PC. Gupta's continued development of SQLWindows, Sybase's purchase of Powersoft (publishers of PowerBuilder), and the release of the Personal Oracle7 products bode well for future scalability in PC database development.

---

DATABASE CHECKLIST

The four primary considerations when evaluating a complex database system are interoperability, affordability, adaptability, and scalability.

-- Interoperability allows you to pick the best components--both hardware and software--and know that they will work well together.

-- Adaptability guarantees the system will accommodate advances in technology.

-- Affordability takes advantage of the plummeting prices in the personal computer and LAN markets.

-- Scalability ensures the ability to add or reduce components to a system to adjust for changing business requirements. Scalability ensures that a database system will always meet your business needs. If your company downsizes, your database application downsizes with you. If your company grows, your system grows.