Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

Anthony Mandic wrote:
>
> Michael Segel wrote:
> >
> > Pablo Sanchez wrote:
> >
> > > Nope, I don't know SABRE nor "The Other" application well
> > > enough to say. If the system crashes when I'm booking a
> > > flight, though, I don't lose my seat therefore I believe my
> > > assertion is correct.
> >
> > No, you don't have your seat until you get a confirmation number.Its that simple.
> > (Confirmation numbers occur after the transaction is completed.
> > Its obvious you haven't written a hotel reservation system.
>
> Its obvious to any programmer that you don't need to have
> written one. The methodology is the same. A confirmation number
> is just another way of saying its the returned key generated from
> an inserted record. If the completed transaction makes it into
> the log prior to a crash then is should be rolled into the
> data when the server recovers. If a confirmation number isn't
> returned prior to the crash, it can be retrieved after the
> crash, if it exists in the database. A well written program
> should be able to cope with this scenario.
>
> > My whole point is that this thread is a waste of breathe.
>
> I'll have to agree with this. Some essentially nonsensical
> points have been raised which only cloud the issues (whatever
> they were).
>
> > Conceputaly the finer the granularity of locks acheived, the better the application
> > will
> > behave and the easier it is to implement an OLTP application.
>
> Sorry, but I can't agree with this. The robustness of an
> application depends on the requirements of the business
> model and the skills of the programmers executing those
> requirements. Locking isn't neccessarily a part of it.
> I'd imagine that there would be plenty of badly written
> application out there (I've seen my share), regardless
> of whats at the backend.
>
> > Now, as to TPC benchmarks, why don't you print the configurations used. :-)
> > (Yes Virginia, I have done benchmarking and I know that everyone cheats:-)
>
> Well, now we know that you do at least. So, your figures can't
> be trusted. You're in an invidious position now.
>
> > > What is obvious is that row level locking doesn't buy you
> > > want you *think* it's buying you when you have a finely
> > > tuned application. All the examples pointed out to me by
> > > folks have been cases of finely tuned apps. See my post to
> > > Mike Segal on finely tuned app's.
> >
> > Uhmm, well no. Scale your application up. Increase the number of users.Then lets
> > talk about performance. Please understand that IMHO, the best place to tune a
> > system is at the app level, not the db engine. Of course, a well tuned engine is
> > important.
>
> I had both a well tuned app and a server with hundreds of
> users pounding it constantly. PLL wasn't an issue. For that
> matter, RLL wouldn't have been either. Thats why I've said
> elsewhere that some of the comments made about requiring
> RLL were specious. Its as you said - it has to be well
> tuned.
>
> > > Facts don't show bias. I'm willing to listen to any facts
> > > that you have to support your claims. As of yet, I've seen
> > > none.
> >
> > Well, how many retail customers use Sybase? Reservation Systems?(SABRE is still
> > mainframe AFAIK)
>
> So, in other words, how many are using a reservation system
> with Informix or Oracle for that matter? So the point becomes
> moot. Mainframe systems have their own issues and complexities.
>
> -am

I know one rather goofy organization that is using Informix for their hotel reservations, and they definitely depend on row-level locking. I've watched the user load increase at a rate that would make me cringe if it was any other data base product, and the equipment was top of the line. Overhead? Sure. I like their approach, put the best damn db engine on the fastest hardware you like, and go from there. It would be ludicrous to think this operation would get by on PLL.

I would hate to have to work around PLL, rather I'd recommend a different product, that not only has RLL, but many other features that Sybase does not. PLL is an achilles heel in OLTP, otherwise Sybase would be the mecca for a lot of companies. This is not what is actually happening. The only thing saving Sybase is Powerbuilder. Sybase is not alone in their problems, witness some of the other elitest companies, who, talking tech, had what they thought was the best. They overpriced the products, and subsequently lost a lot of business. I think Unify had to learn this lesson too. Now perhaps it's Informix's turn. :-)

Somebody here in c.d.informix mentioned a while back the "20/80" rule: use 20% of your customers to get 80% of your revenue. I believe this approach shows time and time again that it will result in failure. Also witness using the same approach towards feature sets. Informix does not sell RLL alone to bolster their products, or just the dubious TPCs, rather the product mix they've had definitely outguns Sybase hands down. Only recently has Sybase figured out that they needed a tool company to bail them out. The engine alone isn't worth it. Think about it, if Powerbuilder only worked on Sybase, would anybody buy it?

As for Oracle, every industry needs a company that sells based on marketing rather than actually having good products. They've got market momentum, but not necessarily anything beyond that. Unfortunately they've proven that the Microsoft method of sales can work for database companies as well.

:-)

Tim

-- 
Tim Schaefer                         \\|//               
tschaefe_at_mindspring.com               6 6               
-------------------------------oOOo---( )---o00o----------------------
http://www.inxutil.com                         http://www.informix.com 
http://www.iiug.org                     news://comp.databases.informix 
mailto:majordomo_at_iiug.org   no subject  body: subscribe linux-informix  
======================================================================