|
|
|
|
|
|
|
|
|
Oracle's Response (2)
|
|
|
6. You contradict yourself here. "You cannot write any DDL with PL/SQL. Oracle dynamic SQL [how you write DDL in PL/SQL] has a different and obtuse syntax." The fact that something is done in a different way doesn't make it wrong, just different. |
|
 |
|
|
Confession: Basic SQL DDL is different whether it is inside a PL/SQL block or outside . Should not English have the same grammar whether it is written in America or in England? Is a consistent English better than an inconsistent English? Is inconsistent English wrong? Should the word "sky" be different whether I am standing inside my house or outside? |
|
|
|
|
|
| 7. This is a security feature. The user who is given permission to execute the procedure does so in the procedure's owner's security domain (a feature Sybase lacks). |
|
|
 |
|
|
|
|
| Confession. The system manager in Oracle cannot manage the system. A feature. Oracle planned this. I am glad Sybase does not have this feature. I am glad that UNIX, and MS Windows do not have this feature either. Now imagine what this feature is going to cost you. |
|
|
|
|
| 8. The statement "There is no if statement in SQL*Plus. "if ..., then drop table ...." is impossible with Oracle." is inaccurate. This can be easily done in PL/SQL, which can be executed in SQL*Plus. Again, just because it is done differently with Oracle doesn't mean it's wrong. |
|
|
Confession: Separate languages. The syntax of data definition language (DDL) within a PL/SQL block in different than DDL outside a block. Again, should not English be the same whether I speak it inside my house or outside my house? When it comes to mathematics and language, right and wrong is not an opinion. When it comes to language, especially a computer language, inconsistencies, by definition, are wrong. This type of inconsistency is a hallmark of Oracle. It will cost your company hundreds of thousands of dollars dealing with them. |
|
|
|
|
|
| 9. Your argument here is not with Oracle, but with the ANSI SQL committee. Oracle implements ANSI standard cursors (something Sybase lacked for years), and you can represent the whole row through the use of the "type" syntax (also ANSI standard). Sybase's proprietary implementation is non-standard and locks developers in. Oracle9i implements backward and forward scrolling cursors, something Sybase lacks. Oracle also implements an array interface, an enhancement to the ANSI standard (see 11 below). |
|
|
Mr. Conway is bringing up a fundamental difference between Oracle and everyone else, not just Sybase. Oracle uses the term cursors to refer to what the rest of the world calls result sets. (The world is correct, mathematically speaking.) Sybase and MS SQL Server send result sets to the client at the same time the queries themselves execute. In contrast, Oracle withholds all results until the PL/SQL block ends. In other words, an Oracle client does not receive any results until after the stored procedure finishes. Then the client must declare, open, fetch, close and deallocate a cursor to retrieve each result set.
Every person knows that processing cursors is slower than processing a result set without cursors. This is true for any database. Oracle's implementation is even slower because Oracle withholds data. Everyone also knows that it is much easier to program a client to process a result set without cursors than it is to program a client using cursors. In Oracle, you have no choice. You must use cursors anytime you want to retrieve data from PL/SQL block, which includes all SQL stored procedures.
It doesn't matter if Oracle's concept of cursors is an ANSI standard. A standard doesn't make it right. For example, it is also a standard to sin. Oracle boasts about its SQL arrays and SQL table row types. Granted. Sybase doesn't have these features. But then again, that is because they are not necessary in Sybase. Since Sybase doesn't withhold result sets, Sybase doesn't need a separate mechanism to make the retrieval of withheld information easier. While Oracle calls the extra syntax a feature, in truth, the extra syntax is necessary because of Oracle's initial design failure.
On a related topic, Oracle has a different syntax for plain cursors and cursors used for dynamic SQL. Also, Oracle's select statement is different inside PL/SQL than outside PL/SQL. You cannot write "select col from table" in PL/SQL. You must declare a cursor for it. This yet another round of language differences is due to the initially wrong implementation of set theory. Just like in math, if you make mistake in the first step, the proceeding steps are also wrong and even further off.
I can talk about wrongness, why it is wrong, and mathematical correctness until you all decompose in front of your monitors. So what am I trying to accomplish here? Why should these things matter to the CIO? These discrepancies and wrongness in Oracle will cost your company hundreds of thousands of dollars. Your developers will be spending man years of time finding work-arounds, programming elaborate but illogical code to make up for deficiencies, learning the syntax, and then relearning the syntax because the syntax follows no memorizable pattern. Oracles SQL languages are not systematic. The CIO will also drive all his developers who are in-the-know out the door. For as the company in New Zealand says, "They consider it punishment to add features to the Oracle module."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
