Re: FLAME Re: What about the Oracle vs Sybase Ads?

des_at_helix.nih.gov (David E. Scheim) writes:
>tcox_at_qiclab.scn.rain.com (Thomas Cox) writes:
>>des_at_helix.nih.gov (David E. Scheim) writes:
 

>I'm not addressing the RDBMS marketplace, but the subset of production
>client-server systems.

According to a rigorous definition of "client server database management system", all four of the following are "client server": Sybase, Oracle, Informix, and Ingres. Remember that "client server" != "RPCs".

Each has a separate DBMS kernel program, and client programs access that server program using a well defined API (or set of APIs). It's just as much "client server" as X Windows, or the MIT Cookie Server. [Actually, I've only heard about the Cookie Server, but the description indicated that it behaved in a fashion to make it truly "client server". Maybe I'll get to use it one of these days.]

>I don't think ease of use necessarily correlates inversely with
>performance. We evaluated another DBMS vendor's product 4 years ago
>which came with a shelf-full of manuals and rejected it because of lack of
>functionality.

In other words, this is a _non sequitur_ with regard to the topic of functionality, which was your original point.

>>Sybase doesn't even have _basic_ ANSI SQL. They're nowhere near the
>>_advanced_ ANSI SQL that nearly every other vendor supports, such as
>>declarative referential integrity.
 

>The Microsoft/Sybase DBMS engine has more front-end tool support than any
>other, which is the real-world benefit of a standard.

Wrong. Factually not true. It ain't so. I'm happy to prove this. Give me your definition of "more front-end tool support" and I will demonstrate the falsity of your position. (Always has been, BTW, despite Microsoft advertising to the contrary.)

In fact, give me as many definitions as you like, and I'll prove your assertion false for all of them, for any point or period of time.

>Enforcement of data
>integrity in production requires capabilities beyond declaritive referential
>integrity, which require trigger or stored procedures.

Oh, absolutely, and that's why the other players (Oracle, Informix, et al.) have implemented all three. Too bad for you Sybase did not. And still has not on most platforms. (Especially if you're using the Microsoft port.)

>>To refer back to the advertisement that started this flamewar, it really
>>is true that a couple of lines of ANSI SQL2 will replace a hundred lines
>>of Sybase Transact-SQL. And the SQL2 code runs *faster*, not to mention
>>being easier to write and maintain.

I see you have nothing further to say on this point. I gather you're conceding that I am correct, yes?

>>Finally, if you're going to make the "practical in production" noise,
>>let's see ONE, just ONE, production site using Sybase's programmatic two
>>phase commit. I've been hearing about this for six years, and the damn
>>thing still isn't PRACTICAL IN PRODUCTION.
 

>You missed my point. I said that distributed DBMS is a bleeding-edge
>technology now whose complexities make the ease of programming a two-phase
>commit a minor issue. Clearly, however, a product that would simplify that
>task and do all the other necessary optimization well would have an
>advantage.

Oh. First, you say that only Sybase offers the features that you need to implement a "real world client server" RDBMS solution. Now you say that Sybase's features are "bleeding edge", and Sybase's marketing mantra of the last six years, "two phase commit", is suddenly revealed to be "a minor issue". And I'm supposed to trust these people?

>Could you give some examples of production applications you have set up
>using distributed client-server computing with other vendor's products?

I've done three small ones -- one a training tracking system that interfaced with a remote human resources database; another a hotel reservation system with four distributed nodes; the last a two node system using two phase commit. In all three cases I was able to use Oracle products, and in two cases (when data got relocated on me, beyond my control) I was able to deal with relocaed data by altering ZERO lines of application code, and ONE line of DBA code. Period.

Better yet, look at the county-wide GIS put in by Orange County, Florida. A true distributed DBMS with each department querying the others, both client-server _and_ distributed, as you request.

Even better, look at some of the Oracle7 early adopters.

Sybase, by contrast, forces me to hard code in the location of all my data elements into all my program code.

And I can't even specify a location at run time using substitution variables -- Sybase *prohibits* that!

If you want more background on this, I can send you hard copies of my published articles on distributed databases and on the definition of "client server".

 -Tom

PS: Lest we leave this on a negative note, let me add that Sybase is fine software, and I have friends who work there. I know plenty of people for whom Sybase software does exactly what they want, and does it quite competently.

-- 
Thomas Cox      DoD #1776   '91 CB 750 Nighthawk   tcox_at_qiclab.scn.rain.com
    The Platinum Rule:  "Do Unto Others As They Want To Be Done Unto"