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 (15036)	1/13/2000 7:42:00 AM
From: DownSouth	Respond to of 54805

Rick, your post is relevant. As one who saw the "row level locking" thing become ONE of the important differentiators between ORCL versus Informix and Sybase, your explanation of the "extention on standards" is a good one. ORCL is doing the same thing today with its Web implementation strategies, and holding its own nicely against MSFT SQL Server at the Enterprise Level.

To: Rickus123 who wrote (15036)	1/13/2000 9:43:00 AM
From: Mike Buckley	Read Replies (1) \| Respond to of 54805

Rickus, Your method of opening Pandora's box is the touch of a master. If only I understood the technical issues, I could agree or disagree with you. --Mike Buckley

To: Rickus123 who wrote (15036)	1/13/2000 11:16:00 AM
From: Thomas Mercer-Hursh	Read Replies (1) \| Respond to of 54805

A couple of thoughts ... Row-level locking is not an extension to SQL since one does nothing in the SQL request to obtain row level locking other than to specify a lock. The comparison is to page-level locking, invoked by the same syntax, in which multiple records can be within the same page. The difference is substantial, but it is a performance issue, not an extension to SQL. Oracle has made extensions to SQL, primarily to provide performance gains, e.g., when the programmer "knows" something about the data which can be used to access it more efficiently. But, I think most of these extensions are more recent. FWIW, the Progress RDBMS had row level locking from day one in the early 80s, but no meaningful SQL option when everyone climbed on that bandwagon. Goes to show the power of standards, particularly when combined with PRGS history of stealth marketing. PRGS is a good case study of how to have a compelling technical advantage and waste it. As to the moderate gain in stock price in the initial RDBMS tornado and the more dramatic one later, my guess is that there were some complicating factors. Certainly, the recent years have seen the commoditization of the database and some serious stumbles by Informix and Sybase, which have helped to propel Oracle into its current highly dominant status, a level of dominance it did not have after the first round because there still appeared to be some serious other contenders in the game. While I am fuzzy on the details, my memory is that Oracle "helped" limit the dramatic gains by some major earnings stumbles back then, which probably help to explain the limited gain in stock price, despite a quite commanding position.

To: Rickus123 who wrote (15036)	1/13/2000 12:22:00 PM
From: emmeling	Read Replies (1) \| Respond to of 54805

As a database developer who's worked with Oracle (and other RDMS's), I believe I can shed some light on some of the technical issues you raise. They mention how, early on, the market for RDBMS was given "a huge boost when Oracle standardized on IBM's SQL language" (RFM, p. 199) So there was really no proprietary architecture, after all. When Oracle standardized on IBM's SQL language, that did not make their architecture non-proprietary -- it simply gave it an open interface. The architecture consists of Oracle's techniques for storing, retrieving, and maintaining data. SQL ("structured query language") is simply a protocol for accessing that database information. An example of an SQL query would be: SELECT MsgID, MsgDate, MsgText FROM Messages WHERE Author = "Rickus123" AND SubjectID = 25851 ORDER BY MsgDate DESC This would retrieve all the messages you've written on this thread in reverse date order. (DISCLAIMER: I have no actual knowledge of SiliconInvestor's data schema, but it probably looks a lot like this. Except that Author is probably stored as a number, not as "Rickus123", similar to SubjectID.) Most modern RDMS's support SQL as a query language, though there are significant differences in dialect. Only the simplest of queries will work across database platforms. Still, this provides a good degree of "openness" (and attempts at standardization of the SQL language are underway). Architecturally, however, there are differences in the way data is stored, ranges of values accepted, how referential integrity is enforced, etc. I can tell you that from a database programmer's point-of-view, it is no simple task to move an application from one database platform to another. Very high switching costs. Hope this helps. --Tracey