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)
Author: Dan G
Date: Fri, 03 Sep 1999 00:00
Date: Fri, 03 Sep 1999 00:00
13 lines
1927 bytes
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)
Author: Ed Prochak
Date: Fri, 03 Sep 1999 00:00
Date: Fri, 03 Sep 1999 00:00
47 lines
2370 bytes
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)
Author: Dan G
Date: Mon, 06 Sep 1999 00:00
Date: Mon, 06 Sep 1999 00:00
52 lines
2561 bytes
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)
Author: David Sisk
Date: Tue, 07 Sep 1999 00:00
Date: Tue, 07 Sep 1999 00:00
68 lines
3856 bytes
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)
Author: Dan G
Date: Wed, 08 Sep 1999 00:00
Date: Wed, 08 Sep 1999 00:00
128 lines
6689 bytes
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)
Author: Kerry Scott
Date: Wed, 08 Sep 1999 00:00
Date: Wed, 08 Sep 1999 00:00
104 lines
5111 bytes
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)
Author: Jerry Gitomer
Date: Wed, 08 Sep 1999 00:00
Date: Wed, 08 Sep 1999 00:00
183 lines
6913 bytes
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)
Author: Webmaster
Date: Sun, 10 Oct 1999 00:00
Date: Sun, 10 Oct 1999 00:00
55 lines
2767 bytes
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