April 1996 Enterprise Windows

by Martin Heller and Ram Tackett

Before we get down to details, let's debunk the popular belief that an organization can have only one database. In fact, many organizations can benefit from using different databases for different purposes.

For instance, an IS shop that has standardized on Oracle for their in-house, general-purpose central database might discover that one division has a crying need which can be met by a third-party package requiring Microsoft SQL Server. Rather than dismiss the third-party package because it doesn't use Oracle, the shop might want to consider using it along with an appropriately sized SQL Server installation. The Oracle installation might reside on a $100,000 multiprocessor machine with hundreds of gigabytes of RAID array storage and be licensed for use by the entire company. The SQL Server installation might reside on a $10,000 single-processor machine with tens of gigabytes of ordinary SCSI disks and be licensed for use by one department. The departmental installation could reduce the load on the Oracle server and allow the rest of the corporation decent response times, while allowing the department to use the best application for its needs.

The databases listed in the accompanying table all support the client/server access model. In client/server computing, SQL or other instructions flow over the network to the database engine, which processes the query on the server or servers. Results flow back across the network to the client.

All the databases we've listed support the relational data model, SQL (structured query language) and ODBC (open database connectivity). Some also support other schemas and interfaces. Network databases can be very efficient for applications that need to navigate a database rather than query it, while object databases are good at storing complex data structures. Multidimensional databases are used for regular data that can't be confined to simple rows and columns. Specialized analytical and statistical databases are also available, but they're beyond the scope of this article.

Both SQL and ODBC are specified by national standards. Unfortunately, in the real world, these standards may not meet everyone's needs. Specifically, a database that supports SQL and ODBC won't necessarily work properly with any given application that uses SQL and ODBC.

The biggest problem with the SQL language is that there are too many versions of the ANSI standard. The ANSI SQL89 standard didn't cover many areas that turned out to be vital to real-world database applications, so each vendor added proprietary extensions to its implementation. With the exception of Sybase and Microsoft SQL Server, which have common origins, no two databases listed have matching extensions.

The bottom line for programmers is that SQL generally has to be tweaked when moving from one database to another. The goal of a uniform SQL that will work efficiently on all database implementations is still a pipe dream.

ODBC is supposed to be the standard interface to SQL databases. It has three levels: basic, level 1 and level 2. Not all the databases listed support all level 2 features. When making a purchase decision, you should have your programmers decide whether a given database's missing level 2 features are critical to your anticipated applications.

ODBC itself is compromised by SQL variations in different databases. All too often, what was supposed to be a portable ODBC application winds up full of database-dependent code. Some ODBC applications even end up doing most of their actual work with ODBC's SQL pass-through feature, in the interest of efficiency. It is possible to write portable ODBC applications for in-house use if the programmers are careful. It's generally not possible to write truly portable ODBC applications that meet commercial standards for speed and flexibility, because each database has proprietary features that can dramatically affect application performance if used effectively.

All the databases in the table support stored procedures, which speed up applications by eliminating repetitive processing and optimization of the SQL language. All but Titanium support triggers. A trigger is a special kind of stored procedure that is invoked automatically when anyone modifies data in its associated table. Triggers are often used to enforce business rules and to maintain the integrity and consistency of related tables. Relational integrity can also be maintained by cascading updates and cascading deletes, while data integrity within a table can be maintained by constraints.

Roughly half the databases listed support index hints. Defining effective indexes for relational databases is an art that requires the programmer to guess what will be needed by the SQL query optimizer. Some database programmers completely forget to define indexes, and others define many complex indexes that are rarely used. Index hints are an extension to SQL that allow the programmer to tell the query optimizer what he was thinking about. This can speed things up a bit, especially if it reminds the programmer to define the correct index in the first place.

Interactive programs for browsing databases often maintain a current record in a database using a cursor. Engine cursors can make such browsing much more efficient, especially on a wide area network.

In large corporations, databases can reside on multiple servers, in multiple locations. In some cases, not all the servers will run the same database software. Cross-server joins allow a query to construct a single view from tables hosted on multiple servers. Heterogeneous joins allow the tables to reside on different database software as well as on multiple servers.

There are standard benchmarks for measuring database performance, controlled by the TPC (Transaction Processing Performance Council). The current benchmark is called TPC-C, and the current results are available on the Internet at http://www.tpc.org/execsum.html. To make the TPC-C results meaningful, they are delivered as audited executive summaries that completely describe the hardware and software used for the test and not only calculate the throughput but also the test configuration's price/performance ratio. TPC-C results are measured in transactions per minute, abbreviated tpmC. For instance, as of this writing, a Compaq ProLiant 4500 5/133 Model 2 with four 133MHz Pentium processors, 1024MB of RAM and 46 4.2GB SCSI disk drives on four SCSI controllers, running Microsoft SQL Server 6.0 on Windows NT 3.51, was able to process 2454.97 tpmC for 2,500 users. With a total system cost of $593,216.30 including five years of maintenance, that gives a price/performance ratio of $241.64/tpmC.

Take those numbers with a big grain of salt. The TPC-C results change almost daily, so you should check them yourself at the time of purchase. Your database vendor should be able to supply you with hard copy.

In addition, your usage patterns may not correspond to the TPC-C test configuration. For a real test, have your programmers put together a benchmark suite that exercises the sorts of access on the types of data that your company actually uses. Then ask database vendors to work with you on benchmarking their products on your target hardware. While that sounds like a lot of work, it's generally much cheaper than deploying a database that will eventually bring your enterprise to a screeching halt.

Editor's note: A longer version of this article is available on the World Wide Web. You'll find it at http:// www.winmag.com/ew.

By Tom Henderson

Can NT Server Quack Like A (NetWare) Duck?

If it looks like a NetWare file server, executes NetWare log-in scripts, uses (and routes) NetWare IPX, has NetWare groups, prints with NetWare printer queues and shows up as a listed server on a NetWare LAN, it must be a NetWare server, right? To paraphrase Groucho Marx, no, it's not a duck-it's NT.

The NetWare file and print server emulation components, called File and Print Services for NetWare (FPNW), make an NT 3.51 server into a passable NetWare file server for $99. FPNW couples to no-cost components in the NT Server box and Service Packs.

The first, and plausibly most handy, service is Migration Tool for NetWare, which reads a Novell file server's bindery information and migrates the information to an NT server. Users, groups, print queues and mail directories plod their way from NetWare to NT in a single pass. Several servers can be collapsed to NT in this way where necessary. Although Microsoft wants the world to use this as a vehicle to migrate and replace a NetWare server, it's also an easy way for administrators to simply move NetWare management and file information to the NT platform. It took Novell years to develop similar utilities for its NetWare 3.x platform.

Another interesting service, Directory Service Manager for NetWare (DSMN), can be coupled with Migration Tool or used as a standalone service to provide a single network user log-in. DSMN makes an NT primary domain controller into a log-in agent for users on a mixed LAN where NT and NetWare coexist. Administrative modifications such as user password changes, group memberships and directory-rights masks can be made to a central location; the changes can then be updated to Novell's bindery or NetWare Directory Service (NDS) when it's running in bindery emulation mode. Banyan also perfected this technique, in which users log in to a Vines environment with united network information that's extensible back to NetWare servers. Both Banyan and Microsoft have been slowed down by the NDS in NetWare 4.1.

In a strange way, DSMN becomes an ersatz directory services method for NetWare 3.x networks. But NDS isn't currently included in these versions of NetWare. When the Client Service for NetWare (CSNW), also known as Microsoft's NetWare Redirector, is installed, it becomes plausible for an NT server to control the hierarchy of the NetWare 4.x directory partitioning system. In the not-too-distant future, the directory services that make NetWare and Vines potent platforms for network administrators are destined to be managed by a single agent-and Microsoft wants NT to provide that agent.

ODSI (Open Directory Services Interface) is Microsoft's initiative for such an agent, and as you might imagine, it puts NT in front of the other network OSes on the LAN. The components of ODSI will drive FPNW and DSMN. An NT log-in becomes the front door to the computing empire-much to the potential chagrin of other network operating system makers. They may have time to get this right, however-ODSI is still in the formative stages, and won't be deployed until Microsoft ships the much-delayed Cairo version of NT Server (currently planned for 1997).