Re: lies damn lies and benchmarks

In article <abdvsm$2dkj$1_at_msunews.cl.msu.edu>, you said (and I quote):
> Hmmm.... It seems that like in many product wars, people's knowledge is out
> of date:

Hmmm, I wish people would stop quoting marketing glossies and manuals when replying to this kind of stuff...

>
> * Sql server had had robust row level locking since version 7. Prior to
> this it was page locking, which could be clumsy.

No it doesn't. You cannot call locking that moves between row, page and table a "robust" mechanism. That is total and unadulterated BULLSHIT. As proven many years ago by Ingres when it tried exactly the same caper.

>
> * I have not seen anything with respect to RI in Oracle that can't be
> replicated in SQL server, including cascading constraints and foreign keys.

Nevertheless it is NOT declarative RI, which is my point. Of course anything can be duplicated. Of course you can re-write anything in Assembler for efficiency too. Question would of course be: why bother? Question also is: why code RI when declaring it is so much easier?

>
> * SQL server has been implemented on systems with 32+ CPUS and 64GB+ of Ram
> with terabytes of online data. This does not match the high end Unix
> systems that Oracle can support, but how many apps need more than 2 CPUS,
> 2GB of Ram, and more than 50GB of online storage?

Heaps. and no, SQL Server does NOT take advantage of all those 32 CPUs, it just CANNOT do it. So who cares how many CPUs the system had when they are not all used by the product? And I have my sincere doubts it could use 64GB+. For the simple reason that the OS it runs on CANNOT address 64GB+ of memory. So let's drop the lah-lah-land "demo" systems, OK?

> With the exceptions of
> very large systems, which are a low percentage of the market, SQL Server can
> go toe to toe with Oracle.
>

Rubbish. It cannot take advantage even of small 8 CPU systems, let alone anything higher.

> * SQL Server has crushed Oracle on tpc benchmarks (www.tpc.org)

LOL!
>
> * Oracle is not fully SQL 92 compliant, so this is a red herring for both
> systems.

No it isn't. Saying that a product is not fully compatible to try to explain away another product that is not even 50% compatible is a furphy.

>
> * SQL Server does comply with required ACID properties for an RDBMS.

Who cares about "ACID"?

> http://newton.uor.edu/FacultyFolder/CKettemborough/Codd12R.html
>
> so... this a non-issue as well. All vendors adapt standards and rules to
> meet their business needs. This doesn't make it right, but you can't use
> this to criticize SQL Server without applying the same criticisms to Oracle.

Nevertheless, Oracle is the RDBMS in the market that satisfies most of them. SQL Server unfortunately has a very poor show.

> * Oracle has more features and a better internal language (PL/SQL).
> However, Oracle sacrifices performance when compared to SQL Server.

Features don't come for free. They save you development and design time also, which are NEVER counted in the TCO rubbish from M$.

>
> * SQL Server runs on only one platform, and is geared completely to this
> platform. In my mind, this is the biggest reason *not* to use SQL Server.
> However, for a small to medium office, why bother investing in an expensive
> Unix system or why bother going through the pain of becoming Linux
> competent? This is where SQL Server shines.

A Unix or Linux system is NOT expensive nowadays. Let's once and for all drop that absolute fallacy!

>
> For small systems I think the argument weighs very heavily in favor of SQL
> Server. For very large systems, Oracle is the clear winner. For everything
> between the two extremes, the choice is not nearly as clear as people would
> like to think.
>

Of course.

-- 
Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam