Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!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: <7400@sybase.sybase.com> Date: 6 Dec 89 18:36:54 GMT References: <4198@rtech.rtech.com> <7323@sybase.sybase.com> <4220@rtech.rtech.com> <7335@sybase.sybase.com> <3584@dev.dtic.dla.mil> Sender: news@sybase.sybase.com Reply-To: tim@sybase.com (Tim Wood) Organization: Sybase, Inc. Lines: 75 In article <3584@dev.dtic.dla.mil> jkrueger@dev.dtic.dla.mil (Jonathan Krueger) writes: >tim@binky.sybase.com (Tim Wood) writes: >>Those aren't client/server architectures, those are RDBMS internal >>archtitectures. > >OK, first principles then: how do you define "architecture"? >For instance, would you accept Blaauw [1970]? Well, if you hum a few bars, I can fake it. :-) Seriously, I'm not familiar with the reference, and would appreciate a summary of the results. My point is, what happens in the DBMS is not the whole computing environment. I'm talking about a higher-level archtitecture, that which the users of the DBMS server are a part, as well as the DBMS itself. The overall computing environment may or may not have the same patterns of order as are found in the DBMS internals. >>ADTs ... are a nice piece of object-orientation in the DBMS. > >Equally true the other way around. And equally silly. >Each model has its merits. Which, wha, way are we going? I don't understand your point. ADT model vs. DBMS model ?? >>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? > >Because it's demonstrably unsafe to do so, it doesn't support >distributing the load, and it makes many query optimizations >impossible. Your company makes quite a deal out of the first >reason, with respect to integrities: why should we expect less >of domain integrity? Good point. I would be interested to know how many current or projected applications out there need high TPS throughput on complex user-defined datatypes. Or whether most of the TPS-critical stuff operates on prosaic things like ints, f4/8's, dates and moneys. >>Then you could be stealing server >>cycles from bread-and-butter transactions. > >One buys a server to execute one's database engine. It needs >what it needs. If one's data types are expensive, it needs more. Agreed, I'm just commenting that the simple-transaction and the ADT workloads probably won't mix well for throughput in the same server. >>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. > >Neither: they're one's data. Consider arbitrarily large fixed point, >for instance. Expensive to implement regardless of where you put it. >Now, what would its use be? Again, it depends on user needs. Some users might need nothing more than BLOB type in the server, and will do most manipulation on the front-end, at least for the near term. Anyone want to comment? A syntactically-correct C-language datatype would be neat. :-) As for "bignum"s, I don't have an application idea offhand (although tracking the Federal debt might be one. :-) You? -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.