scott@shuksan.UUCP (Scott Moody) (10/13/88)
We are making another one of those justifications for our database system and were hoping for some help. Does anyone have a matrix of the relative merits of the main databases around? Specifically Empress, Ingress, Oracle, GemStone, etc. We have been using Empress for about 4 years mainly for its low level database access since that is the level our programmers use. We develope nifty tools for the end users to access the data, and don't provide much SQL level interface. Does an optimizing SQL compiler even match the embedded commands for speed? The matrix should include all aspects of DMBS from the embedded queries, to distributed transactions, to SQL level, (maybe COBAL interfaces?). Thanks in advance. It's hard to step out of our little shell and look at the whole world again. -Scott Moody @ Boeing Mountain Network
mao@eden.Berkeley.EDU (Mike Olson) (02/08/91)
In <1991Feb7.134634.26917@infonode.ingr.com>, tensmekl@infonode.ingr.com (Kermit Tensmeyer) writes > Personnally, I don't see that much need to real relational databases. Most > of the applications that I see in the real world use the database as > complicated ISAM files. Network Databases seemed to use the resources more > efficently. > I suspect that the idea of Relational Data format is more sexier to managers > than the other types of databases. Is there any real world advantage to > RDBMS? if your application is cast in concrete, it may be better to write a special-purpose data manager. flight reservations is an example of an application area that's been pretty successful at doing non-relational data management commercially. however, there are several drawbacks: + NO ad-hoc queries. if you want to get some data out of the database, you have to understand its structure and write a program. + 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. + 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. 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. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
cdm@gem-hy.Inel.GOV (Dale Cook) (02/08/91)
In article <10876@pasteur.Berkeley.EDU>, mao@eden.Berkeley.EDU (Mike Olson) writes: |> In <1991Feb7.134634.26917@infonode.ingr.com>, tensmekl@infonode.ingr.com |> (Kermit Tensmeyer) writes |> |> > Personnally, I don't see that much need to real relational databases. Most |> > of the applications that I see in the real world use the database as |> > complicated ISAM files. Network Databases seemed to use the resources more |> > efficently. |> |> > I suspect that the idea of Relational Data format is more sexier to managers |> > than the other types of databases. Is there any real world advantage to |> > RDBMS? |> |> if your application is cast in concrete, it may be better to write a |> special-purpose data manager. flight reservations is an example of an |> application area that's been pretty successful at doing non-relational |> data management commercially. |> |> however, there are several drawbacks: |> |> + NO ad-hoc queries. if you want to get some data out of the |> database, you have to understand its structure and write a |> program. |> 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. |> + 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. |> + 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. |> 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. ---------------------------------------------------------------------- --- Dale Cook cdm@inel.gov The opinions are mine. The following disclaimer is my employers. ---------------------------------------------------------------------- ========== long legal disclaimer follows, press n to skip =========== Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.
agonzale@nmsu.edu (Agustin Gonzalez-Tuchmann) (02/08/91)
In article <1991Feb7.190050.449@inel.gov> cdm@gem-hy.Inel.GOV (Dale Cook) writes: In article <10876@pasteur.Berkeley.EDU>, mao@eden.Berkeley.EDU (Mike Olson) writes: |> In <1991Feb7.134634.26917@infonode.ingr.com>, tensmekl@infonode.ingr.com |> (Kermit Tensmeyer) writes |> |> > Personnally, I don't see that much need to real relational databases. Most |> > of the applications that I see in the real world use the database as |> > complicated ISAM files. Network Databases seemed to use the resources more |> > efficently. |> |> > I suspect that the idea of Relational Data format is more sexier to managers |> > than the other types of databases. Is there any real world advantage to |> > RDBMS? |> |> if your application is cast in concrete, it may be better to write a |> special-purpose data manager. flight reservations is an example of an |> application area that's been pretty successful at doing non-relational |> data management commercially. |> |> however, there are several drawbacks: |> |> + NO ad-hoc queries. if you want to get some data out of the |> database, you have to understand its structure and write a |> program. |> 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. |> + 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. |> + 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. |> 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). -- Agustin Gonzalez-Tuchmann dbase-l list owner. New Mexico State University Office: SH-165 Computer Science Department Phone: (505) 646-6243 Las Cruces, N.M. 88003-0001 e-mail: agonzale@nmsu.edu
tensmekl@infonode.ingr.com (Kermit Tensmeyer) (02/08/91)
In article <10876@pasteur.Berkeley.EDU> mao@eden.Berkeley.EDU (Mike Olson) writes: >if your application is cast in concrete, it may be better to write a >special-purpose data manager. flight reservations is an example of an >application area that's been pretty successful at doing non-relational >data management commercially. > >however, there are several drawbacks: > > + NO ad-hoc queries. if you want to get some data out of the > database, you have to understand its structure and write a > program. > > + 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. > > > mike olson > postgres research group > uc berkeley > mao@postgres.berkeley.edu I admit that using SQL is a nice interface to doing queries but it's not the only one available. Any standarized interface will insulate the user from the detailed implementaion. (Isn't that why we use layers of calls to hide implementaion from the caller?) If you roll your own DB, then you have roll your own interface as well. From my "limited" activities with data base, don't relational database allow/require you to use any field as a potiential key. Access to records is not limited to indexs only. It is speeded up by the use of indexes. Query Optimization tries to provide some assistance is chosing access methods. Many of the real world relationship involve groups of related data. While those relationships could be expressed as joins, it may be easier to access those data elements as sets either owned or owned by other sets. Example, that comes to mind is my current application (that I'm not supposed to discuss - until it's finished [Client's request]) or maybe genology data storage. Storing information about individuals is great for an ISAM but maintining the relationship of father / Child doesn't change that offen. It is more expensive to derive that relationship by a Join and by using tagged records or Network Sets. -- Kermit Tensmeyer | Intergraph Corporation UUCP: ...uunet!ingr!tensmekl | One Madison Industrial Park INTERNET: tensmekl@ingr.com | Mail Stop LR23A2 AT&T: (205)730-8127 | Huntsville, AL 35807-4201
mao@eden.Berkeley.EDU (Mike Olson) (02/08/91)
as several people have pointed out, a higher data abstraction than the storage manager uses is not exclusive to relational systems. i mis- stated my case. thanks (more or less) for catching me out on this. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
cdm@gem-hy.Inel.GOV (Dale Cook) (02/09/91)
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: |> |> In article <10876@pasteur.Berkeley.EDU>, mao@eden.Berkeley.EDU (Mike |> Olson) makes 3 assertions about the superiority of RDBM systems over |> non-RDBM systems: |> |> |> however, there are several drawbacks: |> |> |> |> + NO ad-hoc queries. if you want to get some data out of the |> |> database, you have to understand its structure and write a |> |> program. |> |> |> |> 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. |> I still don't see what this has to do with RDBM systems. I can "hard code" an RDBMS application just as easily as a non-RDBMS application. This is more a function of the use of 3GL interfaces to your DBMS than to the fact that you are or are not using an RDBMS. Plus, the applications you build on top of the DBMS are independent of any adhoc queries one might do, at least from the ADABAS point of view. |> |> |> + 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. |> Who said anything about "normal procedural languages"??? ADABAS has a "4GL" (whatever that might mean :-) ). The assertion here was insulation from changes to the data. I am no more insulated from changes to the data in say, Oracle than I am in ADABAS. If I delete a field from an Oracle table, any SQL procedures referencing that field will have to be changed. If I delete a field from an ADABAS file, any NATURAL (ADABAS 4GL) procedure referencing it will have to be changed. It doesn't matter if you're using an RDBMS or not. The assertion is nonsense. |> |> + 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. |> In ADABAS, you can create an index on the field(s) in question. |> |> 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). |> Explain, please, why I can't have a data model unless I use an RDBMS. Explain, please, why a poor data model will perform better on an RDBMS than a non-RDBMS. Explain, please, why one can never achieve data independence with a non-RDBMS. I'm not trying to extoll the virtues of ADABAS. I'm arguing that the reasons people have given so far for choosing an RDBMS over a non-RDBMS are not really reasons at all. ---------------------------------------------------------------------- --- Dale Cook cdm@inel.gov The opinions are mine. The following disclaimer is my employers. ---------------------------------------------------------------------- ========== long legal disclaimer follows, press n to skip =========== Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.
clh@tfic.bc.ca (Chris Hermansen) (02/10/91)
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.
ballou@databs.enet.dec.com (02/12/91)
In article <10876@pasteur.Berkeley.EDU>, mao@eden.Berkeley.EDU (Mike Olson) writes: > In <1991Feb7.134634.26917@infonode.ingr.com>, tensmekl@infonode.ingr.com |> (Kermit Tensmeyer) writes |> |> > Personnally, I don't see that much need to real relational databases. Most |> > of the applications that I see in the real world use the database as |> > complicated ISAM files. Network Databases seemed to use the resources more |> > efficently. |> |> > I suspect that the idea of Relational Data format is more sexier to managers |> > than the other types of databases. Is there any real world advantage to |> > RDBMS? |> |> if your application is cast in concrete, it may be better to write a |> special-purpose data manager. flight reservations is an example of an |> application area that's been pretty successful at doing non-relational |> data management commercially. |> |> however, there are several drawbacks: |> |> + NO ad-hoc queries. if you want to get some data out of the |> database, you have to understand its structure and write a |> program. Not necessarily. If you use some form of encapsulation, then changing the implementation would not require rewriting the programs - maybe recompiling. |> + 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. See above. Who said the special-purpose data manager can't be designed correctly, so that one would not have to rewrite all programs. |> + 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. I disagree. If designed well, a special-purpose data manager could allow the implementation to change, which may speed up retrieval/update. |> [...] 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. Or would waste his time... Nat Ballou DEC OODB
mef@Unify.Com (Marvin Fenner (att)) (02/12/91)
In article <1991Feb7.190050.449@inel.gov> cdm@gem-hy.Inel.GOV (Dale Cook) writes: ... good stuff deleted ... > >Nonsense. > ... good stuff deleted ... > >Again, nonsense. > ... good stuff deleted ... > >That may be true, but you haven't given us any real examples why. > And you have given us nothing, period. How about trying your rebuttal again, this time with some visible content?
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/12/91)
As quoted from <1991Feb7.224441.17631@infonode.ingr.com> by tensmekl@infonode.ingr.com (Kermit Tensmeyer): +--------------- | maybe genology data storage. Storing information about individuals | is great for an ISAM but maintining the relationship of father / Child | doesn't change that offen. It is more expensive to derive that relationship | by a Join and by using tagged records or Network Sets. +--------------- Certainly. But nobody claimed that the relational DBMS model required that b-trees be the only index type. Hashed keys are common. Unify (both the old version and UNIFY 2000) has "explicit relationships"/"link indexes", which are restricted versions of network pointers optimized for parent-child relationships --- while Unify's the only one that I know does this, others may well do so. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
cdm@gem-hy.Inel.GOV (Dale Cook) (02/13/91)
In article <tchws3z@Unify.Com>, mef@Unify.Com (Marvin Fenner (att)) writes: |> In article <1991Feb7.190050.449@inel.gov> cdm@gem-hy.Inel.GOV (Dale Cook) writes: |> ... good stuff deleted ... |> > |> >Nonsense. |> > |> ... good stuff deleted ... |> > |> >Again, nonsense. |> > |> ... good stuff deleted ... |> > |> >That may be true, but you haven't given us any real examples why. |> > |> And you have given us nothing, period. How about trying your rebuttal |> again, this time with some visible content? Gee, my mistake. I had hoped one would infer that the same argument I gave against the first point (which you so kindly omitted in your post) applied to the other 2 as well. How's this? Point 1 (condensed): Non-RDBM systems have no adhoc query capability. My rebuttal (condensed): Not true. I've worked with non-RDBM systems with plenty of adhoc capability, e.g. ADABAS. Point 2 (condensed): Non-RDBMS applications are uninsulated from physical changes to the database. My rebuttal (expanded): Not true. I've worked with non-RDBM systems with provisions for physical changes to the data structures without impact to application programs which use them, e.g., ADABAS. Point 3 (condensed): There is no way to speed up non-RDBMS queries without rewriting the application doing the query. My rebuttal (expanded): Not true. I've worked with non-RDBM systems with the capability to specify indexes on fields or groups of fields to speed up queries, requiring no rewrite of existing codes, e.g., ADABAS. There are other non-RDBM systems for which this is equally true, e.g., HP's IMAGE. I do not currently use ADABAS, nor am I saying it is perfect for all uses. I was trying to say that the points made had absolutely nothing to do with whether or not the DBMS is relational. There are good and bad DBMS's, both relational and non-relational. The reasons why relational may be better has nothing to do with the stated points. The "stuff" may have been "good", but it was false. ---------------------------------------------------------------------- --- Dale Cook cdm@inel.gov The opinions are mine. The following disclaimer is my employers. ---------------------------------------------------------------------- ========== long legal disclaimer follows, press n to skip =========== Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.