🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: alt.comp.databases
8 messages
8 total messages Started by Dan G Fri, 03 Sep 1999 00:00
100.000 $ Reward (Oracle 8 versus SQL 7)
#42
Author: Dan G
Date: Fri, 03 Sep 1999 00:00
13 lines
1927 bytes
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.
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#44
Author: Ed Prochak
Date: Fri, 03 Sep 1999 00:00
47 lines
2370 bytes

So do you want us to compare SQL7 with Oracle 7.3 or can we use Oracle
8? (Let's see how can we compare SQL7 favorably to Oracle? I know,
we'll compare against the outdated version!)

Regarding the "reward", I'm not sure what 5 examples I need to give.
 Ones where the web page is wrong about Oracle? (To begin with, lots of
those ideas have been published before. They are not new.)

 Or ones where Oracle is better than SQL7? Given that I don't know as
much about SQL7, I guess I'm out of this one. 8^(

Who's offering the reward money, you? How do I claim it?



In article <7qoogi$h44$1@pollux.ip-plus.net>,
  "Dan G" <Gavrilescu.Daniel@pmintl.ch> wrote:
> 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.
>
>

--
Ed Prochak
Magic Interface, Ltd.
ORACLE services
440-498-3700 <<<NOTE new number


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#45
Author: Dan G
Date: Mon, 06 Sep 1999 00:00
52 lines
2561 bytes
Ed,
If you're not sure about the examples why do you claim the reward ;-x ?.


Ed Prochak wrote in message <7qp68f$s67$1@nnrp1.deja.com>...
>
>
>So do you want us to compare SQL7 with Oracle 7.3 or can we use Oracle
>8? (Let's see how can we compare SQL7 favorably to Oracle? I know,
>we'll compare against the outdated version!)
>
>Regarding the "reward", I'm not sure what 5 examples I need to give.
> Ones where the web page is wrong about Oracle? (To begin with, lots of
>those ideas have been published before. They are not new.)
>
> Or ones where Oracle is better than SQL7? Given that I don't know as
>much about SQL7, I guess I'm out of this one. 8^(
>
>Who's offering the reward money, you? How do I claim it?
>
>
>
>In article <7qoogi$h44$1@pollux.ip-plus.net>,
>  "Dan G" <Gavrilescu.Daniel@pmintl.ch> wrote:
>> 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.
>>
>>
>
>--
>Ed Prochak
>Magic Interface, Ltd.
>ORACLE services
>440-498-3700 <<<NOTE new number
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#46
Author: David Sisk
Date: Tue, 07 Sep 1999 00:00
68 lines
3856 bytes
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.
>
>
>
>
>
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#47
Author: Dan G
Date: Wed, 08 Sep 1999 00:00
128 lines
6689 bytes
David,

1) That's true SQL knows only how to create indexes based simple columns
(not expressions). If you say so that Oracle 8 can , I believe you... BUT
SQL is smart enough and permits computed columns and if you used the
computed column (instead of the function) SQL take automatically advantage
of the indexes of the columns that compose the computed column(if
available).
BTW Oracle can create indexes based on multiple columns (and take advantage
on this)?.

The point is that in the article from http://www.dbpd.com/vault/9801xtra.htm
at paragraph 4 it was mentioned that (I quote):
"Do not make indexes on those columns that are used only with functions and
operators in the WHERE clause of queries."
and that's not true for SQL this is what I sustained !.

2) I don't know if SQL 7 uses bitmap indexes (probably not) but uses
(internally) the index intersection and unions for sure (read the
documentation and checked with the execution plans).
BUT you've missed the point again.

3) All my statements referred to the mentioned article. It's no reference on
the bitmap indexes in that one ;-0

4) That's not entirely true as well (did you really check your assertions
?!):
I am quoting from documentation :
"To use partitioned views, you create several identical tables, specifying a
constraint to determine the range of data that can be added to each table.
The view is then created using these base tables. When the view is queried,
SQL Server automatically determines which tables are affected by the query
and references only those tables. ".
Obviously the above refers to the query horizontally partitions. (I haven't
mentioned the creation of the partitions and vertically partitions ...)

5) here is another example that you didn't read carefully may statements. It
is no reference in that article to fact tables and warehouse related issues.
So your example is out of scope.

6) definitely you have to re-check your assertions (anyway the 6) point is
again out of scope !!!):
FYI, I am quoting again from technical doc's:
"The query optimizer recognizes certain commonly occurring database and
query structures, such as star or snowflake schemas, and chooses an
execution plan based on a careful cost analysis particularly well-adapted to
queries against these structures. For example, the SQL Server 7.0 query
optimizer uses the techniques of Cartesian product index manipulation and
semi-joins to process queries against star schemas.
"
about the reward ... I am still waiting for min 5 assertions about what I've
mentioned in my first article (read carefully ;-)).

Dan.

David Sisk wrote in message ...
>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.
>>
>>
>>
>>
>>
>
>
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#48
Author: Kerry Scott
Date: Wed, 08 Sep 1999 00:00
104 lines
5111 bytes
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.
> >
> >
> >
> >
> >
>
>
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#49
Author: Jerry Gitomer
Date: Wed, 08 Sep 1999 00:00
183 lines
6913 bytes
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.
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
Re: 100.000 $ Reward (Oracle 8 versus SQL 7)
#50
Author: Webmaster
Date: Sun, 10 Oct 1999 00:00
55 lines
2767 bytes
This is a test only.

Dan G wrote:

> Ed,
> If you're not sure about the examples why do you claim the reward ;-x ?.
>
> Ed Prochak wrote in message <7qp68f$s67$1@nnrp1.deja.com>...
> >
> >
> >So do you want us to compare SQL7 with Oracle 7.3 or can we use Oracle
> >8? (Let's see how can we compare SQL7 favorably to Oracle? I know,
> >we'll compare against the outdated version!)
> >
> >Regarding the "reward", I'm not sure what 5 examples I need to give.
> > Ones where the web page is wrong about Oracle? (To begin with, lots of
> >those ideas have been published before. They are not new.)
> >
> > Or ones where Oracle is better than SQL7? Given that I don't know as
> >much about SQL7, I guess I'm out of this one. 8^(
> >
> >Who's offering the reward money, you? How do I claim it?
> >
> >
> >
> >In article <7qoogi$h44$1@pollux.ip-plus.net>,
> >  "Dan G" <Gavrilescu.Daniel@pmintl.ch> wrote:
> >> 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.
> >>
> >>
> >
> >--
> >Ed Prochak
> >Magic Interface, Ltd.
> >ORACLE services
> >440-498-3700 <<<NOTE new number
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Share what you know. Learn what you don't.
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads