Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!crdgw1!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!mtxinu!sybase!ohday!tim From: tim@ohday.sybase.com (Tim Wood) Newsgroups: comp.databases Subject: Re: Is RDBMS unproven technology? (Flames to follow....) Message-ID: <10494@sybase.sybase.com> Date: 10 Aug 90 20:03:17 GMT References: <1073@ashton.UUCP> <10371@sybase.sybase.com> <13532@ulysses.att.com> <10419@sybase.sybase.com> <13545@ulysses.att.com> Sender: news@Sybase.COM Organization: Sybase, Inc. Lines: 87 In article <13545@ulysses.att.com> swfc@ulysses.att.com (Shu-Wie F Chen) writes: >In article <10419@sybase.sybase.com>, tim@ohday.sybase.com (Tim Wood) writes: >|>In article <13532@ulysses.att.com> swfc@ulysses.att.com (Shu-Wie F >Chen) writes: >|>>In article <10371@sybase.sybase.com>, tim@ohday.sybase.com (Tim Wood) > >If you are talking about end users and canned applications, the model >used isn't that important. If you talk about the programmers who >implement the canned application, then it is a different story. >Frankly, I am now confused. Your previous arguments made sense for >application programmers, but now you say you were really talking about >end users. Making it very simple: The relational model eases application development. This tends to encourage application development. So the app. programmer and the users benefit: the users get more needs met because the app. programmer's job is easier because the relational model makes app. writing easier. >Well, have there [b]een any released competitive products (by ... >competitive, I don't mean better than other *relational* DBMSs, but >better than any *other* DBMSs)? Sure. Relational has made the metrics of non-procedural access and data independence part of the "competitiveness" equation. RDBMS's are competitive because people are buying them. They are now competing on another crucial metric, performance, so making navigational systems even less attractive. >|>>... [J]oins are a real big performance killer for relational systems. >|>Not if they are pre-optimized or pre-computed. >What do you mean by pre-optimized or pre-computed? What if I performed >a join that was not pre-optimized or pre-computed? Pre-optimized: the query processing strategy is determined and that strategy is saved in the DBMS in a pre-compiled form. The DBMS needs merely to execute the strategy to obtain the results. Pre-computed: the RESULTS (not just the strategy for obtaining them) are saved somewhere (in or out of the DBMS) saving the need to recompute them. A long ad-hoc join will tend to dent transaction processing performance (see Marc Zwieger@Sequent's thread on this). So maybe you run ad-hoc users at lower priority, or defer the volume updates for overnight (but allow your DBMS's view of the world to diverge several hours from reality), etc. >How many RDBMSs scale well (besides Sybase, of course ;-)? Better yet, >how many RDBMSs scale? I'm not motivated enough to do the research to answer this question. If I was a prospect or a consultant (or in Marketing :-), I would be. My point is, the important DBMSs will be ones that can operate efficiently at various scales, from departmental 80386(tm) to nerve-center mainframe. >|>Hmm, I've been developing the opinion that query compilation is a largely >|>solved problem (cost-based optimizers, etc.), but that fundamental things >|>like I/O management and access methods policies need a lot more work >|>in RDBMS. So sounds like we have a good discussion ahead of us :-) . >I/O management and access methods policies are orthogonal to the data >model. These issues are just as important in navigational models. Of course, but these issues haven't been as well addressed in relational models, and they are the ones (in most cases) that are hindering the ability of relational systems to scale well. The fact is, decreasing numbers of people are interested anymore in making navigational systems faster. >The reason I suggested query compilation as a point of study is that in >navigational systems, [ good summary of the application programming >issues deleted ]. [But in relational, programmers ] >are dependent on the query compiler to map their logical view and >operations to physical operations. I don't believe current compilers >have reached the expertise of [human] coders in performing this mapping. Probably not. The important ($) question for most users is, do today's optimizers do a GOOD ENOUGH job on ENOUGH queries, without doing a HORRIBLE job on nearly ANY query. The more decision support (ie ad-hoc queries) an organization does, the more important the optimizer will be. However, a decent optimizer has become a check-off item for any RDBMS today, as it should be: that is one of the things that allows them to perform at all on those easily-written (but sometimes hard to answer) ad-hoc queries. -Tim --- Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim One day, when I can afford enough lawyers, I will speak for a whole company. For now, I speak just for myself.