markh@rtech.rtech.com (Mark Hanner) (04/09/90)
I realize that it is sometimes hard to believe that this newsgroup is not just a sounding board for obscure theoretical arguments, but in fact the vast majority of readers are users rather than builders of databases. Nico is really missing Dave's point, which is what the vendor provides is the only thing the user has to work with... In article <2b56xrv@unify.uucp> nico@unify.UUCP (Nico Nierenberg) writes: >In article <5180@rtech.rtech.com> davek@rtech.UUCP (Dave Kellogg) writes: >> >>I couldn't have stated the problems with an RPC-based interface any better. >>However, not all products use RPCs as the basis for distributed processing. >>RPCs are not the same as distributed databases. >> > >What in the world are you talking about? RPC stands for remote procedure >call and is an implementation mechanism for routing requests over a >network. It has nothing to do with a user view of a distributed or >non-distributed database. This is true: if two products both give you a feature, you don't care how each product does it as long as they both meet your needs. But the dicussion here centers around the definition of the "distributed database" feature. It is NOT the same thing to provide "distributed database" as it is to provide "all the pieces you need to build your own distributed database." Vendors having the latter almost universally call this "distributed database" anyway. >> . . . . RPCs are NOT distributed databases and shouldn't >>be sold or interpeted as such. > >Yes and 'C' compilers aren't distributed databases, good point :-(. Let the buyer beware. The salesman may say "distributed database" (or "object-oriented" or <your_favorite_buzzword_here>), but you may get nothing more than a C compiler... >> >>Dave Kellogg >>Ingres Corporation >>"Statements made are my own and not necessarily opinions of my employer" >Nicolas Nierenberg "No matter where you go, >Unify Corp. there you are." >nico@unify cheers, mark -- markh@rtech.COM "Crass generalizations may be justified by admitting 10 exceptions." -- marnie applegate
nico@unify.uucp (Nico Nierenberg) (04/10/90)
In article <5213@rtech.rtech.com> markh@rtech.UUCP (Mark Hanner) writes: >I realize that it is sometimes hard to believe that this newsgroup is >not just a sounding board for obscure theoretical arguments, but in fact >the vast majority of readers are users rather than builders of databases. > >Nico is really missing Dave's point, which is what the vendor provides >is the only thing the user has to work with... > >In article <2b56xrv@unify.uucp> nico@unify.UUCP (Nico Nierenberg) writes: >>In article <5180@rtech.rtech.com> davek@rtech.UUCP (Dave Kellogg) writes: >>> >>>I couldn't have stated the problems with an RPC-based interface any better. >>>However, not all products use RPCs as the basis for distributed processing. >>>RPCs are not the same as distributed databases. >>> >> >>What in the world are you talking about? RPC stands for remote procedure >>call and is an implementation mechanism for routing requests over a >>network. It has nothing to do with a user view of a distributed or >>non-distributed database. > >This is true: if two products both give you a feature, you don't care >how each product does it as long as they both meet your needs. But the >dicussion here centers around the definition of the "distributed database" >feature. It is NOT the same thing to provide "distributed database" as it >is to provide "all the pieces you need to build your own distributed >database." Vendors having the latter almost universally call this >"distributed database" anyway. > I am afraid that my point was missed. I am not being an apologist for any particular implementation. My issue was that there is no current database which provides an RPC package and calls it "distributed database." They may indeed use RPC's to implement their system. I do agree that various vendors offer pieces of a distributed implementation and call it "distributed." >>> . . . . RPCs are NOT distributed databases and shouldn't >>>be sold or interpeted as such. >> >>Yes and 'C' compilers aren't distributed databases, good point :-(. > >Let the buyer beware. The salesman may say "distributed database" (or >"object-oriented" or <your_favorite_buzzword_here>), but you may get nothing >more than a C compiler... > >>> >>>Dave Kellogg >>>Ingres Corporation >>>"Statements made are my own and not necessarily opinions of my employer" >>Nicolas Nierenberg "No matter where you go, >>Unify Corp. there you are." >>nico@unify > >cheers, >mark > >-- >markh@rtech.COM >"Crass generalizations may be justified by admitting 10 exceptions." > -- marnie applegate -- --------------------------------------------------------------------- Nicolas Nierenberg "No matter where you go, Unify Corp. there you are." nico@unify
rbp@well.sf.ca.us (Bob Pasker) (04/11/90)
nico@unify.uucp (Nico Nierenberg) writes: -In article <5180@rtech.rtech.com> davek@rtech.UUCP (Dave Kellogg) writes: --I couldn't have stated the problems with an RPC-based interface any better. --However, not all products use RPCs as the basis for distributed processing. --RPCs are not the same as distributed databases. -What in the world are you talking about? RPC stands for remote procedure -call and is an implementation mechanism for routing requests over a -network. It has nothing to do with a user view of a distributed or -non-distributed database. well, you're both right. dave is right when he says that not all products use RPCs for distributed databases and nico is right when he says that it has nothing to do with a users view of anything. So what? Your wrong, nico, about RPCs and networking. RPCs have nothing to do with networking, by the way. RPCs are a model for building client/server-type applications and have NOTHING to do with routing requests. See, RPCs are an Application Layer service element and routing is a Network Layer thingy (that's networking jargon.) --Distributed databases do exactly what you need. Ingres/STAR provides a --glboal data dictionary that keeps track of what objects live where, so you --don't need to preface the tablename with SERVER-LOCATION.TABLE-NAME. -- --For transparency, all you want to say is -- -- select commission from salary, sales where salary.empid = sales.empid; -- --Ingres/STAR lets you do that, without all the messy non-transparent --references to what "server" or what node the database lives on. That's --called location transparency and distributed databases deliver it. -- -Nice commercial. But true. dave can't help that he's in marketing. its a shame that bright people like him wind up there sometimes. -As a matter of fact I will -bet you that somewhere deep in your networking layer you have something -that looks like RPC's. I'd be very happy to take this bet. There is no RPC interface, per se, in INGRES/net or GCA (INGRES' application layer for databases). The SPECIFIC problem with RPCs is that, as commonly defined and implemented, there is a set of parameters passed as an RPC invocation from client to server and a single response returned (i.e. a return value.) When you perform a select that returns more than one tuple you have more than one response. The model then becomes somewhat awkward because you have to make reverse child procedure calls back to return the data: client ---- SELECT requuest ---> server <--- tuple 1 request ---- /* these are child RP calls */ --- tuple 1 response ---> <--- tuple 2 request ---- /* these are child RP calls */ --- tuple 2 response ---> <--- tuple N request ---- /* these are child RP calls */ --- tuple N response ---> <--- SELECT response ---- What is RDA doing with RPCs? Is ROSE in or out? --RPCs are probably useful for some things. However emulating distributed --databases isn't one of them. RPCs are NOT distributed databases and shouldn't --be sold or interpeted as such. -Yes and 'C' compilers aren't distributed databases, good point :-(. C'mon give him a break. Believe it or not there are people out there touting RPCs as the 'only way to do distributed database.' Dave was trying to make a point. Noone claims that a c compiler is a any kind of a database. MUMPS, however, is a different story :-> -nico@unify oh, now I understand. Gee, and I thought that we were going to keep cross-vendor slander out of comp.databases. -- - bob ;----------------------------------------------------------------- ; Bob Pasker, San Francisco, CA | rbp@well.sf.ca.us ; +1 415-695-8741 | {apple|pacbell}!well!rbp