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

In article <1993Feb18.090825.23139_at_qiclab.scn.rain.com> tcox_at_qiclab.scn.rain.com (Thomas Cox) writes:

>des_at_helix.nih.gov (David E. Scheim) writes:
 

>>Having worked with client-server systems, I can say that Sybase prospered
>>because it set up the foundation for a client-server architecture that
>>works. Their product is technically sound, providing the functionality such
>>as stored procedures and triggers that permit deployment of real-life
>>multiuser applications.
 

>By saying this, you imply that the 90% of the RDBMS marketplace that is
>NOT using Sybase is somehow not "real world". Nice try.

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

>>Futhermore, my experience has been that a Sybase
>>server can be installed in about half-an-hour and administered from two
>>small manuals.
 

>And I can set up Paradox under Netware with one manual. Yay. What's
>your point? That ease of administration is a good thing? (I agree.)
>That it outweighs other drawbacks, which in Sybase are numerous? (I
>disagree.)

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.

>>Distributed computing is a tough technical challenge to do
well, requiring >>complex types of optimization to be practical in production. I >>must admit I am somewhat skeptical about the forthcoming production >>capabilities in this arena from a vendor which up to now did not even offer >>optimization in its basic SQL queries. -- David Scheim

> [See also a reply by D. Druker on Oracle optimizers]
See my reply about putting a good spin on a disfunctional optimizer.  ...
>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. Enforcement of data integrity in production requires capabilities beyond declaritive referential integrity, which require trigger or stored procedures.

>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.
 

>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.

>I have no axe to grind. I have customers and I solve their problems.
>When those problems are best solved by Sybase products, that's what I
>use. But the pure fact is that there are fewer and fewer such problems
>left in the world.

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

>I'm sorry if that makes you uncomfortable, Dave.
I have no axe to grind, and only wish to bring a reality check into this discussion.

> -Tom
>--
>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"

/*********************************************************************/
/*                      --- David E. Scheim ---                      */
/* BITNET: none                                                      */
/* INTERNET: desl_at_helix.nih.gov          PHONE: 301 496-2194         */
/* CompuServe: 73750,3305                  FAX: 301 402-1065         */
/*                                                                   */
/* DISCLAIMER: These comments are offered to share knowledge based   */
/*   upon my personal views.  They do not represent the positions    */
/*   of my employer.                                                 */
/*********************************************************************/