In the December issue of DBMS, David Linthicum writes about the pros and cons of fat servers and fat clients in "Client/Server Collapse." He specifically speaks about problems of scalability with Oracle when putting stored procedures and triggers in the server, but he implies that this was generally true for any RDBMS.
Although I don't have any experience with Oracle, I do have considerable client/server programming experience with Ingres. The idea that stored procedures and rules within Ingres require a greater percentage of the DB server to process than if that code is in the client applications is just not true.
According to Linthicum's description of one Oracle system, using stored procedures and triggers caused the server capacity to drop from 50 users to 25 users. It seems to me that one of the following would hold true in this case:
The way to find out if this is indeed the case is to see if the Oracle front ends are about the same size under the latest version as they were when Oracle did not use the client/server model. (Ingres front ends went from around 256K in version 5.x to around 11K in 6.x and above.) If both front ends are about the same size, the odds are that the same version of the server is running in both architectures. If such is the case, then Oracle doesn't truly support the client/server model.
This structure means that Oracle has a single-user server supporting multiple front-end processes, which are themselves mini-servers. This argues that Oracle will not scale nearly as well as other RDBMSs that are truly client/server because each front-end process needs the resources necessary to handle functions that, in a true client/server architecture, are handled by the server.
For example, if under the standalone architecture an RDBMS has front ends of 256K each, but under the client/server model, the same RDBMS uses front ends that weigh in at 10K apiece, under the standalone model, 100 users would eat up 25MB for front ends alone, whereas under the true client/server approach, only 1MB would be used. Using a true client/server approach shrinks the front-end processes significantly. More users can be accommodated more quickly and with less system degradation to a given hardware platform than with any other current method.
If a client/server RDBMS uses 256K front ends and normally handles about 50 users on a given hardware platform, then any other RDBMS that makes full use of client/server technology to shrink the front ends to a reasonable size should be able to handle at least 500 users on the same platform.
Phil Brisco
brisco@charm.net