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

On Mon, 01 Dec 1997 14:35:10 -0600, Michael Segel <Mikey@NOSPAM.King.of.MyDomain.NOSPAM.Segel.com> 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. I still wonder where he got the idea he'd not lose his seat while booking if the system crashes. : :My whole point is that this thread is a waste of breathe. :Conceputaly the finer the granularity of locks acheived, the better the application :will :behave and the easier it is to implement an OLTP application. : :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:-) /Sarcasm on NO! You're kidding!!!!! /sarcasm off : :> Gary> I'm not refuting it. I'm saying it's not based on :> Gary> Sybases lack of row-level locking. :> :> I can't parse the above point. Would you elaborate? :> : :He's saying that there are other things that Sybase does well, inspite of not :havingrow level locking. Would you care to elaborate. It was the same point I was :trying to :make. Only you thought to say SNIP! :-) Dunno how I missed his "can't parse that". You're right however, that's indeed what I was referring to. : :> Sybase is fine and so is Informix and as a matter of fact, I :> like Oracle's architecture too. They all have problems and :> good points. As a developer it's important to exploit the :> good points rather than the bad one's. But I stray... :> : :No, this whole thread is a stray. That's the point I was trying to make since :itssilly to say that page level locking is better than row level locking. Uh, exactly. : :> 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. Yes, a combination of both with the app level being the most 'noticable' in performance. What Pablo misses while asking for exact benchmarks etc is USER perseption. You can make an application LOOK faster. Example: You have an app that needs to read many rows. One version displays "Reading rows ..." The second displays the count as it goes. The PERCEPTION is that it's faster. (Actually, it's a bit slower because of the display) : : :> 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) It is. : :That's the real test. It is. gburnore@netcom dot com or gburnore@netcom databasix com --------------------------------------------------------------------------- How you look depends on where you go. --------------------------------------------------------------------------- Gary L. Burnore | '۳'''''''ۺ''''''''''۳ | '۳'''''''ۺ''''''''''۳ DOH! | '۳'''''''ۺ''''''''''۳ | '۳ 3 4 1 4 2 '' 6 9 0 6 9 '۳ spamgard(tm): zamboni | Official Proof of Purchase =========================================================================== PGPprint: C63B CF4E 1B71 4D7E C6F8 AF4E 338D 5CB4 KeyID: 0x0F7EDBD9 (RSA) finger gburnore@netcom.com for public key ---------------------------------------------------------------------------