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

In an ideal world ,(Like the world of TPC-C benchmarks) Pablo is possibly = correct in what he is saying. In my world I have to contend with denormalised data structures that do = not accurately relect the way the business processes interact. People do = do things like put a flag on the pallet record because it is quick easy = and dirty and gives them what they want; until they run into contention = issues with the 5 other unrelated processes that all want to read the = pallet table at the same time, so they can get *their* flags. In this outfit we support legacy applications developed over the last 10 = years in Cobol, now running against the Informix database. (And = nowadays I stand at the gate of the database with a big axe ready for = horrible data structures, but unlike the Chinese emperors, I do not have = the option of re-writing history) Even with lock mode set to wait the system would be deadlocking right left = and centre if we abandoned row level locking. To me it seems that ; if you have *not* got row level locking; you code = around it. It may even enforce a better discipline, as Pablo suggests. = (Still it seems to me to be making a virtue out of neccessity) But if you = have got row level locking, you just thank diety and move on to the next = problem. It ain=27t marketing hype; it is a very useful practical tool. In our = situation a bit of CPU time is a lot cheaper than concerning ourselves = with re-writing a bunch of applications that have got a 31 Dec 1999 sunset = on them in anycase. Page level locking may be more efficient of the CPU; but it seems to me = that it is just shifting the inefficiency back to the user, who has to = wait while his well written program handles the fact that it cannot get = access right now to a record that is locked; not because someone is = actually using it, but simply by proximity. =20 rgds Peter Tashkoff <tashkop=40iname.com> Zespri International Limited Std Disclaimers Apply All rights reserved. No party may use this document to vilify another. Zespri New Zealand Kiwifruit, The World=27s Finest >>> Pablo Sanchez <pablo=40sgi.com> 25/11/97 17:28:26 >>> >>>>> =22Perry=22 =3D=3D Perry Dillard <perry.dillard=40iname.com> writes: Perry>=20 Perry> =5B The old row level versus page level crud deleted =5D Perry, All I=27m saying is that the hype you have fallen for is really not there. Most problems with locking are centered around the application not the RDBMS. If you have a finely tuned application in (gasp=21) any RDBMS, the application will do well. Take a look at the TPC-C=27s (which is a=20 tuned application) and you=27ll see that the current numbers for Informix are something like 24K and Sybase it=27s something like 34K. Sybase is doing page level locking and Informix is not (in certain areas). =20 I=27m certain that a new -C value for Informix will come out topping even Oracle=27s 50-odd K but that=27s not the point. The point is: 1) Rarely is there an application that requires as much throughput as a -C 2) Row level versus page level locking is all marketing hype crap. If you want to believe, go for it... but look for the problems in your application, not at the RDBMS Ultimately, people believe what they want to believe... this argument is so old... yawn. ps: I=27ve written quite a few app=27s and have DBA=27d for several years. =20 pps: I do like Oracle=27s Server Process scheme. I can bet one can push the disks really hard with all them readers. --=20 Pablo Sanchez =7C Ph =23 (650) 933.3812 Fax =23 = (650) 933.2821 pablo=40sgi.com =7C Pg =23 (800) 930.5635 -or- pablo_p=40p= ager.sgi.com=20 ---------------------------------------------------------------------------= ---- I am accountable for my actions. http://reality.sgi.com/pablo =5B = /Sybase_FAQ =5D