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

From: Anthony Mandic <no_sp.am_at_agd.nsw.gov.au>
Date: 1997/12/02
Message-ID: <34838B25.75A1_at_agd.nsw.gov.au>#1/1


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 Received on Tue Dec 02 1997 - 00:00:00 CET

Original text of this message