Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!van-bc!tfic.bc.ca!clh From: clh@tfic.bc.ca (Chris Hermansen) Newsgroups: comp.databases Subject: Re: Database Comparisons Message-ID: <1991Feb9.235141.24243@tfic.bc.ca> Date: 9 Feb 91 23:51:41 GMT References: <10737@pasteur.Berkeley.EDU> <1991Feb7.134634.26917@infonode.ingr.com> <10876@pasteur.Berkeley.EDU> <1991Feb7.190050.449@inel.gov> <580@opus.NMSU.Edu> Reply-To: clh@tacitus.UUCP (Chris Hermansen) Organization: Timberline Forest Inventory Consultants Lines: 100 In article <580@opus.NMSU.Edu> agonzale@nmsu.edu (Agustin Gonzalez-Tuchmann) writes: >In article <1991Feb7.190050.449@inel.gov> cdm@gem-hy.Inel.GOV (Dale Cook) writes: [stuff deleted] > > Excuse me, but this has nothing to do with RDBMS format. I've worked with a > non-relational DBMS system that has adhoc query capability, you don't have > to understand the structure any more than you do an RDBMS. The particular > DBMS I refer to is ADABAS, and I would wager there are others. > >There has to be an underlying model, though. In hard-coded application >the files and application programs very often result in different >solutions to common problems. This makes it difficult to create an >ad-hoc query program. Sure, but the underlying model could be hierarchical (sp?), network, relational; That's Cook's point, I believe. Another example of a non-relational database management package with an interface to conduct ad-hoc queries is FOCUS. > > > |> + you're not insulated from changes in the the storage structure. > |> if i change the way that records are organized on the disk (a > |> thing that i might do, for example, to speed up certain types > |> of searches) you have to rewrite all the computer programs that > |> use the database. > |> > > Nonsense. > >If you use a relational data base manager you can achieve data >independance with less pain than in normal procedural languages. Again, the fact that it's a *relational* database manager doesn't really matter. What you're happy with is a "nice" front end (ie, not ESQL/C) to do your ad-hoc queries in. > > |> + as a corollary to the last point, there's no simple way for you > |> to speed up a query short of recoding the program that implements > |> it. on a relational system, i can just define an index and let > |> the optimizer do the right thing. > |> > > Again, nonsense. > >I don't see how you can speed up a query without rewriting the >program. Thus it makes sense to me. And yet again: this is an artifact of the query manager, and has nothing to do with whether it's a "relational system" or something else. > > > |> in general, query optimizers have proven to be about as good as competent > |> programmers in picking the right query. a programmer with extra information > |> about the data on the disk can sometimes do better than an optimizer, but > |> the additional cost of programming every query by hand has to be considered > |> as well. finally, all the commercial people are claiming that we're on > |> our way to twenty-way joins. i don't really believe that, but if it's > |> true, then the programmer does not exist who can hand-optimize the query > |> in finite time. > |> > |> in short, relational systems have a substantial advantage over network and > |> hierarchical database systems for common business applications that involve > |> ad-hoc queries and frequent schema changes. > |> > > That may be true, but you haven't given us any real examples why. > > The biggest advantage I have seen is that they enforce somewhat more rigor > in your data design, e.g., you can't have repeating groups. > > >I think the biggest advantages is having a data model ( it enforces >rigor on design, if that's what you want), data independance, and >I think the most important -and often most overlooked feature-- >it gives non-programmers a big chance to ask questions through >the query manager of the rdbm (or dbm). Well, I don't know about twenty-way joins, either :-). Seriously, it seems to me that there is a substantial group of problems that the standard query tools (eg SQL) provided for use with relational databases (or others?) don't address in a nice clean fashion. For example, connectedness problems in graphs. In these cases, one might be better off using Prolog, say, or ??. Nevertheless, this is still really an issue of the query language, not the (possibly deeply) underlying database implementation. Chris Hermansen Timberline Forest Inventory Consultants Voice: 1 604 733 0731 302 - 958 West 8th Avenue FAX: 1 604 733 0634 Vancouver B.C. CANADA clh@tfic.bc.ca V5Z 1E5 C'est ma facon de parler.