Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!binky!tim From: tim@binky.sybase.com (Tim Wood) Newsgroups: comp.databases Subject: Re: Intelligent Databases (was Re: DB Procedures) Message-ID: <7335@sybase.sybase.com> Date: 4 Dec 89 05:17:37 GMT References: <4198@rtech.rtech.com> <7323@sybase.sybase.com> <4220@rtech.rtech.com> Sender: news@sybase.sybase.com Reply-To: tim@binky.UUCP (Tim Wood) Organization: Sybase, Inc. Lines: 112 In article <4220@rtech.rtech.com> davek@rtech.UUCP (Dave Kellogg) writes: >In article <7323@sybase.sybase.com> tim@binky.UUCP (Tim Wood) writes: > >>Client/server is 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. > 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: >1. Server-Per-User [i.e. front-end/back-end process pair per user] >2. "No Server" [i.e. DBMS linked with user application in one process] >3. Single Server [i.e. DBMS is one process multiplexed across n users] >4. Multiserver [i.e. DBMS is multiple cooperating multiplexed processes] You've given a good overview of RDBMS architectures. >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? Those aren't client/server architectures, those are RDBMS internal archtitectures. Only #3 & #4 allow enough control over the workings of the DBMS to achieve the specialization of function that is part of the definition of being a server in a client/server environment. >>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'm not yet satisfied on this. One can observe a computing installation looking for characteristics of a client/server organization: is the user ("client") view of computing resources as a directory of named services which the client can access (if properly authorized) without regard to how that service is implemented, where it resides, etc? Do the offerers of the services ("servers") have full integrity control over the resources they make available, and define the interface through which it will be used? Is there an overall "object orientation" in the environment? If the answers to these questions is yes, then IMO you are probably looking at a client/server-based environment. >I will add that "intelligent database" is certainly >in the same league of technical descriptiveness as client/server. > >For completeness, I'll add that Ingres Corp defines an intelligent database This is what I have wanted to know... >[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. > "Objects" (things more complex than characters and numbers) are managed >via standard SQL, [except] 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?) No's 1 & 2 and the rules feature belong under client/server, IMO. They pertain to the full responsibility of the DBMS to maintain integrity. A "server" can't really be one without the intelligence you describe. No. 3 could be client or server, as I see it. On one hand, ADT's (oops, abstract data types--echo from my RTI days :-) are a nice piece of object-orientation in the DBMS. On the other hand, it might be more flexible in practice for the application to handle the many arbitrary object types that a user could create. Many abstract operations might be sufficiently handled in the presentation-level stuff running on the client. Why burden the DBMS with these functions, especially if they are CPU intensive? Then you could be stealing server cycles from bread-and-butter transactions. I'm just not sure if ADT's are closer to the front-end processing than to the data management, and more of a decision-support feature. >[...] rules allow unlimited rules/table/operation (triggers, >and I'm sure Tim will correct me if I'm wrong .... >(Tim, are triggers still silent when they don't forward chain as expected, >and is the forward chaining depth now greater than zero?) I'll get to this in a later posting; I'm not at work so can't research an answer as complete as you'd want. By "forward chaining", I assume that's what we call "cascading", i.e. triggers firing other triggers. >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... 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 Now I'm more prepared to accept "intelligent database". Thanks. -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK. Brought to you by Super Global Mega Corp .com