Re: Microsoft destroys TPC-C records!

Well some people deal in words, others deal in actions.

To everyone who read this article and agreed with it - please go ahead and start implementing solutions in SQL Server. You'll simply speed up the 'evolutionary process' which will eventually see the true technical champions win out in the end.

Microsoft is a marketing machine first, RDBMS vendor second. Ever noticed the lack of technical details and reasoned arguments in their literature - ever wondered why they're not there - ever wonder why every MS representative you ever see quoted in the press is Mr(Mrs) XXX YYYYY , Product Marketing Manger????

When was the last time you ever saw a detailed quote from Mr(Mrs) AAA BBBB , Technical Development Manager???

Get the picture yet?

MS has done the job of box-shifting very well. It just happens that the boxes contain software Cd-Roms that some young(ish) programmers dreamt up.

David P.

Oracle Certified DBA.

Norris wrote:
>
> In comp.databases.sybase Death to Norris! <norris_at_dickhead.fwit.com> wrote:
> > Brian Peasland wrote:
> >>
> >> Norris wrote:
> >> >
> >> > See the Locking differences between Oracle and SQLServer
> >> > http://www.microsoft.com/sql/productinfo/transadvantage.htm
> >>
> >> This article is complete and utter crock of b.s.
 

> > Of course it is. That moron norris hasn't got a clue what he
> > is citing. Please everyone just ignore the dickhead and just
> > maybe he will go away for a while.
>
> What about this article:
>
> ========== FROM THE EDITOR ==========
>
> Greetings,
>
> To tweak or not to tweak, that is the question. For 'tis nobler to
> have a database that is fast than one that is tunable.
>
> Shakespeare didn't work with many databases, but I'm sure he'd
> agree that speed is superior to tunability. Still, I've talked with
> a lot of people recently who position Oracle as better because it's
> "more tunable" than SQL Server. True, Oracle 8i has more than 400
> tunable parameters while SQL Server 7.0 has fewer than 50--and that
> number drops in SQL Server 2000. The argument is that, because Oracle
> offers many more tuning parameters than SQL Server, you can make
> Oracle run more efficiently than SQL Server. However, this argument
> has a fatal foundational flaw: that "manually tunable" equals
> "optimal performance."
>
> Database administrators and developers easily fall for this
> assumption. The engineer deep down inside us desperately wants to
> believe that we're smarter than the machine. We love to feel needed
> and powerful, like we do when our knowledgeable tweak produces an
> astonishing performance improvement. But it's time we got over
> ourselves. We're not that smart. And most of our tuning successes
> have come as a result of working with a database that couldn't do
> the job for us.
>
> Remember when we optimized queries by listing tables and conditions
> in a certain order in the FROM and WHERE clauses? Wasn't that "tuning"
> the query? Today, no one seems to mind that cost-based optimizers find
> the best execution path for our queries. In fact, we'd laugh at a
> database product that didn't have a sophisticated cost-based optimizer.
> Why don't we expect the database engine to have the same level of
> intelligence?
>
> One goal in rewriting SQL Server was to produce a product that "just
> works." To that end, Microsoft reduced or eliminated many
> administrative requirements in SQL Server 7.0 and incorporated into the
> database code the job of tuning the database for shifting workloads.
> Microsoft says the result is a database that has few manual tuning
> parameters but that features rich automatic-tuning functionality,
> letting the server constantly monitor and adjust memory allocation,
> optimizer plans, and locking to fit the latest application
> requirements. Competitive database vendors spin this to say SQL Server
> isn't tunable. Perhaps both statements are true.
>
> Don't lose sight of the real goal. We don't want tunable databases;
> we want fast databases. I've seen plenty of DBAs "tune" their system to
> run incredibly slow. By the same token, a simple set of tuning
> parameters doesn't mean the database engine is simplistic or incapable
> of tuning itself. So, the next time a database salesperson says, "SQL
> Server isn't tunable," you can exclaim, "Great! That's one less thing I
> have to worry about."
Received on Sat Apr 08 2000 - 00:00:00 CDT