Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!amdahl!rtech!davek
From: davek@rtech.rtech.com (Dave Kellogg)
Newsgroups: comp.databases
Subject: Intelligent Databases (was Re: DB Procedures)
Message-ID: <4220@rtech.rtech.com>
Date: 3 Dec 89 07:56:18 GMT
References: <4198@rtech.rtech.com> <7323@sybase.sybase.com>
Reply-To: davek@rtech.UUCP (Dave Kellogg)
Organization: Ingres Corp., Alameda CA
Lines: 125

In article <7323@sybase.sybase.com> tim@binky.UUCP (Tim Wood) writes:

>Client/server is a specific technical concept.  No one owns it, no one
>can claim they own it.
>This is quite different from the "intelligent
>database" slogan, which doesn't express a specific technical concept.

First off, as evidenced by the recent debates about client/server and 
other debates which haven't been on the net, it's pretty clear that
client/server isn't quite so "specific" as you may think.  Although I
haven't been following the nitty-gritty too much, have (and do correct me
if I'm wrong) you all been discussing between the (at least) 4 different 
implementations of the SERVER side of client/server?

To me, it seems like you are off discussing schedulers when you could off
discussing higher-level architectural issues.  Sure, when a database takes
control of the OS it could do better scheduling (does anyone?), but how
about answering the original (more than one-month old question?) from the
guy at Kodak about basic differences in client/server systems.

As I see it, the biggest differences come in the process implementation 
of the SERVER.  That is, I see at least 4 different types of client/server
systems (not to mention hardware vendor database systems, like Tandem) each
with their own strengths and weaknesses.

(examples not guaranteed 100% correct, but I'll try my best)

1. Server-Per-User

	Single single-threaded server per user (i.e. 2 process per user model).
	Examples:  Oracle on UNIX, Informix, Ingres Release 5

	Strength:  multiprocessing
	Weakness:  overhead on heavy loads

2. "No Server" or Shared Memory Server

	No distinct OS server process exists.  Rather the database engine
	code is mapped into shared memory and runs in the context of the 
	application code, and usually in a protected access mode (e.g. on
	VAX/VMS in executive or supervisor mode)
	Examples:  Rdb, Oracle on VMS.

	Strength:  Reduces processes on VAX/VMS (in networks, too?)
	Weakness:  No access modes on UNIX, not implementable 
		   without sacrificing memory protection of server.
		   (must degenerate to server-per-user to protect server's
		   address space on UNIX)

3. Single Server

	Single multithreaded server which has exclusive control over a set of 
	databases. 
	Example:  Sybase

	Strength:  Reduced per-user overhead
	Weakness:  No multiprocessor support

4. Multiserver

	Multiple multithreaded servers which may access same sets of databases.
	Examples:  Ingres 6.x, Interbase[?]

	Strength:  Reduced per-user overhead without exclusing multiprocessors
	Weakeness: No parallelization of queries (which nobody does yet anyway)
		   Does symmetric multiprocessing, not parallel processing 

The above seems like a better level for discussion, and I would be appreciative
if anyone could correct any misconceptions in the above.  And back to my other
theme, if client/server is such a specific "technical term" than how come I
can easily fire off four separate "client/server" architectures and
differentiate them in all of about 20 lines?

>Tim continues...
>This is quite different from the "intelligent
>database" slogan, which doesn't express a specific technical concept.

Finally, given that I've demonstrated my primary point (that client/server 
is by no means a "specific technical term," but rather to a large extent 
a simple marketism), I will add that "intelligent database" is certainly
in the same league of technical descriptiveness as client/server.  And, in
fact, I'll wager that in the upcoming months/years that both intelligent
database and intelligent systems will come to receive the same general
attention as did client/server.

For completeness, I'll add that Ingres Corp defines an intelligent database
[server] as one that manages all three of 

	1. simple business data (characters, numbers and the like)
	2. knowledge of data interrelationships (e.g. referential integrity)
	   and knowledge of business policies.
	3. objects more complex than characters and numbers (e.g. ordered
	   pairs, arrays, vectors, matrices, latitude/longitude, cubes, circles,
	   time series, etc.)

Knowledge is managed primarily via rules, which are differentiated from 
triggers in the data sheets I mentioned in the last posting.  At the highest
level it's simply that rules allow unlimited rules/table/operation (triggers,
and I'm sure Tim will correct me if I'm wrong allow only 1 trigger/
table/operation), and recursion (which triggers lack?).  In addition, there
are some forward-chaining issues and behavior at the boundary value.  (Tim,
are triggers still silent when they don't forward chain as expected, and 
is the forward chaining depth now greater than zero?)

"Objects" (things more complex than characters and numbers) are managed via
standard SQL, with the notable exception that users may define their own 
datatypes from scratch (not simply a domain-like remapping of an existing 
type) along with user-defined "builtin" SQL functions, and user-defined 
context sensitive overloading of classical operators (e.g. what does "+"
mean in the context of a point or complex number?)

Finally, and thanks to those who've hung in this long, I'll add that the
term intelligent database does have some credibility in the literature as
well.  Although our implementation is quite different from the hypothetical
[?] one mentioned in the following database text, many of the ideas and 
principles in the areas of bulding intelligence in at the server level
are similar to those mentioned in:

	"Intelligent Databases"
	Kamran Parsave et al.
	Wiley Publications, 1989


Dave Kellogg
All opinions are of course my own and not necessarily those of my employer


Brought to you by Super Global Mega Corp .com