Re: Quote from comp.object

On 2007-03-01, DBMS_Plumber wrote:

> One principle objective of relational DBMS systems is to separate data
> management from application code, allowing several applications to
> share one database. This leads to situations where the DBMS is
> implemented as one set of (operating system) processes, and the
> application(s) in another(others).

Once again, there is nothing the relational model that would dictate such an arrangement. The RM only says you have to have a single, coherent interface to the DB. It doesn't tell you how that interface should be implemented. A fully distributed implementation does just fine. Teradata again serves as an example.

> Most hierarchical systems--IMS, Pick etc -- share with many embedded
> data managers -- Berkeley DB, etc -- the property that the data
> management is co-resident with the application code in a single
> process. By avoiding the cost of moving data between processes,
> hierarchical data managers adopting this architecture gain
> considerable response time and throughput advantages.

As I said, there is nothing in the relational model that would stop the precise same thing from happening. If your embedded SQL/RA is amenable to compile time optimization and you're guaranteed to run on the same machine the RDBMS runs on, it's just common sense to tightly bind the server and the application. If not, you'll incur some communication penalty that couldn't be avoided in any case.

In any case, the RM lives at a higher level than such optimizations. It does so precisely to enable independence of lower layer data organizations and/or interfaces. Thus, we expect that a good implementation of the relational model would take full notice of all the possibilities for physical optimization. A fully local, shared memory, zero copy, in-process, inline, mere-descriptive-metadata organization is just one of the low level organizations possible under the model.

In the end such an organization would probably be faster than an IMS database because every overhead that could be cut would have been, yet higher level operations like multitable joins which allow for cost amortization would have been properly declared in relational syntax, and fully exploited. Such savings are not possible under the interface offered by IMS, evenwhile they're the lifeblood of the RM.

> That said, it doesn't amount to a hill of beans in practice. Business
> flexibility trumps computer performance every time (so long as
> performance meets some minimal, usually pretty low-bar, level).

On the contrary. Performance is quite significant, because endusers do not want to wait and managers do not want to invest stupidly, in the opportunity cost sense. As you and others have said in the past, the point essentially is that an RDBMS allows one to substitute cheap, abundant machine power for expensive coding effort by expert programmers. The problem isn't so much about flexibility; it's about who's there to take care of the demand, a machine or a human, and also how much transaction costs accrue due to interface design between the customer and the supplier. The RM excels in both regards, which is why it's so much better than hierarhical or network organizations.

-- 
Sampo Syreeni, aka decoy - mailto:decoy_at_iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2