🚀 go-pugleaf

Hi Kerry,

    Okay, you made me realize the most significant difference
between Oracle and SQL Server.

    If you want to make 100K recommend Oracle and become an
Oracle DBA!

    If you are willing to make considerably less recommend SQL
Server!

All kidding aside both products have their place and there is
obviously quite a bit of overlap between them.  You raise the
question of how many of the unique Oracle features are actually
used (I presume you mean in the typical Oracle installation).  To
me the major advantage of these nifty features is that they will
be available in the future if I need them to accommodate changing
business requirements.

If business requirements were static and SQL Server would meet my
business requirements I would use it,  but since business
requirements can change faster than all but the fastest rapid
prototypes can change their code to match I will stick with
Oracle.

Quite frankly, given the amount of change I have seen in business
practices during the course of my career I feel that it would be
remiss to recommend a product which can run out of gas just when
I need it the most.  SQL Server is limited in features as
compared to Oracle, DB2, Informix, and Sybase.  SQL Server is
also limited in terms of the hardware performance of its
platforms as compared to the other products I named all of which
run on Unix and some of which run on mainframes.

regards
Jerry Gitomer





Kerry Scott wrote in message <#bHU5bh##GA.251@cpmsnbbsa02>...
>1) Big deal.
>
>2) Although bitmapped indexes work best for low cardinality
columns.
>
>3) Right, no bitmapped indexes. Of course Oracle has no
clustered index
>(unless you count the index ordered table, but I wouldn't
recommend it for
>most installations, neither does Oracle).
>
>4) SQL Server 7.0 has partitioned views. They work basically the
same as
>Oracle 7's did, with partition elimination.
>
>5) 3rd party DSS software can do this.
>
>6) SQL Server does. And of course Oracle has no OLAP services.
>
>In other words, each RDBMS has features the other does not have.
Each has
>very similar features, also. However, many of the highly touted
Oracle
>features come at a cost in overhead, maintainability, and
administration.
>Many also fit into a very few "niche" scenarios. If you want to
tweak the
>hell out of some app, and have a $100K DBA, go for it. If you
just want a
>very good performing, low maintenance, low cost database, that
works for 90%
>of most RDBMS apps, then go for SQL Server.
>
>And one last thing, I wonder what % of  Oracle DBAs have really
used any or
>all of those nifty features that are "marketed".
>
>Kerry
>
>David Sisk <davesisk@ipass.net> wrote in message
>news:ZSjB3.1469$tp2.1714@news.ipass.net...
>> Okey dokey:
>>
>> Using Oracle8.1 as a reference:
>>
>> 1)  SELECT statements with a function applied to the WHERE
clause will use
>> an index (with no modification of syntax) if (all other
parameters held
>> constant and suitable) the index is created on the function of
the column
>> rather than the column itself.  SQLServer7 can't do that.
>>
>> 2)  The cost-based optimizer will determine which index(es) to
use or
>> whether to do full table scans.  With bitmap indexes, the CBO
can do
>unions
>> and intersections of the indexes to get the necessary row ID's
to
>retrieve.
>> SQLServer7 can't do that.
>>
>> 3)  Speaking of bitmap indexes, SQLServer7 doesn't have them.
Only B-tree
>> indexes are available.
>>
>> 4) Oracle can automatically perform partition-elimination on
partitioned
>> tables and partitioned indexes.  SQLServer7 can't do that.  In
fact,
>> SQLServer7 doesn't support any form of partitioning.
>>
>> 5)  Oracle provides summary management, which allows a query
directed at a
>> large fact table to be transparently redirected to a much
smaller summary
>> table, completely behind the scenes with no modification in
SQL syntax.
>> SQLServer7 can't do that.
>>
>> 6)  (Just for good measure)  Oracle recognizes dimensional
models (ie.
>"star
>> schemas") if they are designed correctly, and will
automatically use "star
>> join" processing algorithms rather than more traditional
relational
>> algorithms.  SQLServer7 can't do that.
>>
>> If you don't buy any of this, check the benchmarks on
www.tpc.org and/or
>the
>> documentation on technet.oracle.com.
>>
>> Email me and I'll reply with the mailing address you can send
the $100,000
>> check to.   :=)
>>
>> Best regards,
>>
>> --
>> David C. Sisk
>> Need tech info on Oracle? Visit The Unofficial ORACLE on NT
site at
>> http://www.ipass.net/~davesisk/oont.htm
>> Like original modern rock?  Listen to song samples and buy a
CD at
>> http://www.mp3.com/disparityofcult
>>
>>
>> Dan G wrote in message <7qoogi$h44$1@pollux.ip-plus.net>...
>> >Check this out first !:
>> >http://www.dbpd.com/vault/9801xtra.htm
>> >
>> >Second: I am not an Microsoft fan (even if I am using MS
SQL).
>> >
>> >Allmost all Oracle commandments (applicable to SQL 7) doesn't
need to be
>> >applied with SQL 7 because the query optimizer is smart
enough.
>> >Allmost all Oracle enhancemets (written in the article)
apllied as well
>> with
>> >SQL 7.
>> >The one who can give more than 5 examples against the above
statements
>> worth
>> >the prize ;-).
>> >
>> >All the best.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>