Re: Microsoft destroys TPC-C records!

Hi all,
I've had such a flame war with a ms sql7 developer who has tried to "prove" the drawbacks of oracle with EXACTLY the same example ;-)) So let's take a look at this example and the actual impementation: Let us suppose that the acounts are held in a single table (accounts) for simplicity. accno number, balance number 15,2 Oracle:
select balance into some_variable from accounts where accno=the_account_of_the_family FOR UPDATE; if some_variable<300 then

    update accounts set balance=some_variable-300;     commit;
else

    roolback;
    raise exception no_funds....;
endif;

Can you tell me which account will be overdrawn?

So let's expand our bank to a netbank 24/7 with many customers. Let's say transactions are possible also during the night (so you have always tousnads of transactions at any time ).
Suppose you are a manager in this bank and want to know "who much money do we actually have NOW?"...
The query you need is very simply:
select sum(balance) from accounts;
Oracle will immediately give you an answer. SQL7 won't!!! You will have to wait untill all transactions are commited or rollback untill you ever get an answer. And what happens if a (or some) cutomer just went away of their house or their browser crashed? You have to wait for a timeout of (I guess) about an hour. Do you think it's good?

About reading uncommited data. I think it's not a bad idea if YOU NEED something like that , but I think it could surve only as an additional feature (next to reading commited data without blocking)
I can imagine that it could be a very good feature for some e-commerce apps, where you want to monitor BOTH commited AND uncommited data.... "how many people do try to buy know and how many of them have really bought something......."

Norris wrote:

> See the Locking differences between Oracle and SQLServer
> http://www.microsoft.com/sql/productinfo/transadvantage.htm
>
> In comp.databases.sybase Nuno Souto <nsouto_at_nsw.bigpond.net.au.nospam> wrote:
> > On Mon, 03 Apr 2000 12:33:08 GMT, jahorsch_at_my-deja.com wrote:
 

> >>>
> >>7.0 has true row level locking now.
 

> > Remains to be seen how solid or resilient it is. I'm reminded of the
> > Ingres "row-locking" turning into table locking when you least
> > expected. Usually when the engine was over-loaded. Right when you
> > want it most. But hey! Did they rattle-on about it...
 

> >>Server 7.0 is a brand new engine with only compatibility left.
 

> > That to me spells untested, buggy, fragile software. Exactly what
> > should be used to keep critical data. :-)
 

> >> MS
> >>hired some of the best engine builders in the field to make this one.
> >>They made it very scalable (as long as NT can scale that far.)
> >>
 

> > I'm reminded here of the utter crap Sybase used to put out about how
> > "modern" their code was compared to ORACLE, yadda-yadda.
 

> > They basically picked the code of the old Britton-Lee database
> > machine, renamed it, made it run on UNIX and called it a "modern"
> > product. Didn't even bother changing the names or the language.
> > Still have one of their initial company presentations where they
> > clearly say they were all ex-Britton-Lee. No wonder they took AGES
> > porting to VMS, darn thing was never written to be portable!
 

> > And for a long time, MS was sucked into that one too. Now they are
> > using the same technique. Heck, they didn't even bother to change the
> > low-level data management. It's still fixed block, based on "devices"
> > and all that crap. "best engine builders" my ass!
 

> > The day MS can produce a database that can run equally well on NT or
> > UNIX or a mainframe is the day they become relevant. Until then, it's
> > just proprietary and locked-in. For all intents and purposes, behind
> > the times and old-fashioned in its design strategy.
 

> > Tying a database to an OS exclusively is no demonstration of any good
> > design technique whatsoever. It's making it dependent on the OS.
> > Change the OS and the whole thing craps. Worse: once they start going
> > that way, it's very difficult to introduce new stuff at the OS level
> > without severely impacting the "tied-in" software. Result: the OS
> > progress stales.
 

> > Note: not to say NT is bad. I think it's a darn good OS. It has many
> > flaws, like any other. But overall, it's a very good effort.
> > Particularly since NT4/SP4. Jury still out on 2000. However, for
> > large and medium systems UNIX is so far ahead it's not even funny. If
> > only MS would get rid of that moronic "registry" idea and the multiple
> > re-boots every time anyone so much as clicks on an OK button...
 

> > But a good database is one that doesn't depend on intimate OS
> > cooperation to run efficiently. That creates a heap of problems for
> > both the OS and the database. As MS will find out.
 

> > Cheers
> > Nuno Souto
> > nsouto_at_nsw.bigpond.net.au.nospam
> > http://www.users.bigpond.net.au/the_Den/index.html
>
> --
> http://www.cooper.com.hk
Received on Sat Apr 08 2000 - 00:00:00 CDT