Oracle's Response (10)

45. Since PL/SQL can have multiple SQL statements, each ending in a semi-colon, what alternative is there?
Confession and a Regret: Oracle uses the same symbol to end a SQL statement as it does to execute a command. If you can imagine Sybase forcing you to use "go" to signify the end of each statement, despite the fact you don't want to execute the statement, you get Oracle. This feature of Oracle, which apparently even Mr. Conway regrets, is contradictory, confusing, and often runs your programming projects into the ground. ODBC session programs cannot process normal Oracle commands and PL/SQL blocks because such ODBC programs do not expect a single symbol in the same language to stand for two mutually exclusive commands

One alternative is to prevent ";" from ever meaning "execute". Oracle should change its internal programming and adopt this standard. Oracle already has "\" to mean execute. Oracle could keep that. Even a back-slash, though cryptic, not intuitive and problematic in C printf () statements, is better that the existing incompatibility.

The other alternative is use Sybase. Sybase doesn't need a character to terminate a statement. By virtue of Sybase's design, Sybase knows when one statement starts and the last one ends without the aid of a helper character. Sybase architecture is the apex of mathematical minimalism. A good thing. Nothing is wasted. Nothing unnecessary is forced, even if it is as small as a single character terminator. Sybase is mathematically minimalist from the ground up. One sees this philosophy in CT-Library, Open Server library, the server and database architecture, and Sybase's SQL language implementation. From a technical point of view, Sybase is doing everything right. It is refreshing to see.
Go to Fractal Site
Go to Oracle
46. This is incorrect. In 9i, you are prompted whether you want to terminate the import or export.
I am not sure about 9i. But in 8i, if you hit ctrl-C in the middle of an import, Oracle will terminate the import for the current table, but then will proceed to import the next table. The only way to break out of the import is to go to UNIX and kill-9 the process.
So, Brian, many of your statements are contradictory and your facts are inaccurate, and those that are technically accurate merely point out there are differences between Oracle and Sybase. Why not just say "I don't like Oracle and here's why"?

There are a few Sybase facts to consider: Sybase has lost the database war and is not investing in their database product; Sybase's marketshare is < 4%, and falling; no one is buying new Sybase licenses meaning they have no money for R&D; there have been 0 new features in recent years that would entice a customer to buy Sybase or switch to Sybase. Sybase
is merely providing basic product support as the users slowly fade away. The company is destined to go the way of Ingres & Informix, acquisition, or oblivion. A smart DBA will not fight Oracle's market share, but benefit from it.

Cheers

Joe :-)
My only wish for any piece of software, is to just get it right. The software should technically challenge me, not infuriate me. The reason I dislike Oracle is because Oracle is light years away from getting it right. Out of the last three years of employment, I have literally wasted one year of my career cleaning up after Oracle. I believe my life and my employer's time is more valuable than cleaning up after lousy software. I could have used that year to be productive--to do the company good. But Oracle wasted it. The waste cost my company $120,000 in immediate employment expenses, plus an estimated $500,000 because I should have been programming new features instead of developing work-arounds for Oracle.

Mr. Conway's final statement contains the "Market Share" argument. One cannot talk to an Oracle fan without hearing it. Personally, I always thought the reason to buy a product is because it is a good product.

Oracle has major technical problems with its products. Sybase has major problems with its sales force in America. John Chen should replace Sybase's sales force with Oracle's. Oracle should scrap their product and hire a programmer that has studied set theory. As for R&D expenses, the effectiveness of a product is not measured by its R&D budget. Most of Oracle's R&D budget goes to solving Oracle's own architecture flaws. For 9i, Oracle's R&D paid for locally-managed tablespaces and now-optional rollback segments. For these two new "features", Oracle has now arrived where Sybase was 12 years ago. For the next version of Oracle, Oracle 10i, Oracle may improve another handful of problems. With any luck, Oracle might arrive where Sybase was 11 years ago.

As for the statement about a "DBA's responsibility to not fight but benefit from market share", I say this. It is not the duty of the DBA or database programmer to "benefit" from market share. The duty of the DBA and the database programmer is to solve problems. Unfortunately, unknown to the Oracle fan, Oracle gives him twice as many problems than he initially had to solve. And unfortunately, there's some sick psychology at work there which also benefits Oracle. Because of the cornucopia of problems Oracle adds to the legitimate problems, the Oracle developer actually thinks he is being more useful. An Oracle programmer actually enjoys finding work-arounds. The more elaborate work-around, the better. The Oracle programmer can even share his "expert" Oracle knowledge with his fellow Oracle friends. Gives them something to talk about, to keep them busy. Expense?  What does that matter? Oracle has market share.
© 2010 Talus Software. All Rights Reserved.

Home | Buy Software | Privacy