Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Strategies & Market Trends : Gorilla and King Portfolio Candidates -- Ignore unavailable to you. Want to Upgrade?

To: Rickus123 who wrote (15058)	1/13/2000 3:08:00 PM
From: emmeling	Respond to of 54805

the switching costs, in my opinion, have more to do with the non-SQL aspects of the RDBMS implementation than with SQL itself. I think it's both. You pointed out that my example query would run the same on all database platforms. True, but that was a very simple query. Give me something with a few outer joins in it, and I'll have to code it differently for every database on the planet! ANSI-SQL will help once the RDBMS's become adequately compliant with it, but you can still write a syntactically correct ANSI-SQL query whose functionality is not supported by the underlying database engine. (Nested outer joins are a killer!) Maybe the adoption of SQL was really an end-run around the "open" part of "open proprietary architecture"! &ltg&gt --Tracey

To: Rickus123 who wrote (15058)	1/13/2000 3:16:00 PM
From: Thomas Mercer-Hursh	Respond to of 54805

standardization on SQL was a key to achieving gorilla power. In fact, my memory is that Oracle really pulled a fast one because IBM came out with the standard, making it single vendor by source initially, but offering it as a standard, but then did a terrible job of actually delivering. Oracle aced this by saying "sure, we'll take your standard" and then delivering. This was a lot of their early growth. Row versus page level locking is not so much a client/server issue as it is a scalability issue. Certainly a part of Oracle's success has been being able to say "my database is bigger and faster than your database", thus not only attracting the top level, but also anyone below that who was concerned about growth. Bingo. I have had precisely the same experiences. But the switching costs, in my opinion, have more to do with the non-SQL aspects of the RDBMS implementation than with SQL itself. Indeed, in a good development environment, like Forte, for example, one can write the application so that it will run against any SQL database transparently, but one may gain better performance by noticing when the database is Oracle and supplying additional performance hints.