|
|
|
|
|
|
|
|
|
|
|
Oracle's Response
|
|
|
|
Talus Software received this letter from: |
|
|
Joseph E. Conway
Systems Engineering Manager
Oracle Federal
Oracle Corporation
1910 Oracle Way
Reston, Virginia 20190
|
|
 |
|
Mr .Conway agreed to let us publish this letter. This letter is typical of those we receive from Oracle fans. But there are three differences. 1) This letter is from an Oracle representative. 2) It is well thought. And 3) I like Mr. Conway. From our communications, I deem Joseph to be a kind, nice and humble man.
This letter has the same conclusion as all Oracle fan letters. "You should buy Oracle because everyone else buys Oracle." |
|
|
 |
|
|
|
 |
|
|
|
|
|
| Download the Microsoft Word document containing the full response. |
|
|
|
Dear Brian:
I ran across your site, and found it intriguing, especially the stuff on Oracle. There are numerous factual inaccuracies in your representation of Oracle that I hope to address & correct. I hope you will find the humility and professional integrity to update your site.
I understand that you have a long history and therefore strong preference for Sybase. I think it fruitless to try to address, much less change, your emotional attachment to Sybase, so I will deal with the issues you raised rather than your perceptions. Your "Oracle Facts" section should be called "Oracle Perceptions and Petty Annoyances" instead, since the facts are mostly error and bias.
1. While it is true Oracle does not support IEEE format representations directly, Oracle's representation of numbers support 38 digits of precision on both sides of the decimal point, much higher than the IEEE standard or the capabilities of Sybase or most native number representations on all but supercomputers. The only thing a developer should worry with is if the number stored is returned accurately & precisely, and the operations on that number are accurate. Everything else is mere window-dressing and technical snobbery.
|
|
|
Confession: No support of IEEE format. While it true that developers shouldn't worry about precision and accuracy, the fact is that Oracle's NUMBER format must always be converted to and from IEEE. The conversion does force a certain kind of developer to worry. A developer of engineering and science applications must know propagation of error and know exactly how the limitations of accuracies and translation affect his algorithms. His ability to deal with it means the difference between a working and non-working CAD/CAM system. My concern over non-IEEE compliance is not technical snobbery, but rather the experience of programming CAD/CAM applications myself. Systems like Oracle are taboo because they are loose over matters of conversion. No conversion is preferable. When there is no conversion, the engineering developer knows what he is storing and what he is getting at all times.
Conversion errors are actually a minor concern compared to the other NUMBER format problem. There is a larger penalty because NUMBERs are variable length. Any database professional knows about the tremendous I/O slow-down that accompanies processing variable length columns. Deferred-updates, and page chaining, the latter an added extra Oracle feature. These are bad things, even terrible considering every number in an Oracle database suffers on account of them. |
|
|
|
|
|
|
| 2. If you define a float or integer or double, and make an assignment, INSERT or SELECT, Oracle handles the conversion seemlessly. If you do the math on the server, no conversion is necessary. |
|
|
Confession : Needless translation. Sybase or MS SQL Server has no need to translate. Why employ a translator if both parties should be speaking English? Oracle handles the conversion seemlessly, but the problem is the need to convert in the first place. Mr. Conway says that no conversion is necessary at the server." But that is wrong. The CPU, any CPU, does math only on IEEE datatypes. So the server is doing it too. |
|
|
|
|
|
|
| 3. This is inaccurate. Bit operators are fully supported, and have been since at least Version 7 (see BITAND in the SQL Language Reference). The bit operator of "standard programming" is different in Oracle than in C or C++. Requiring SQL, a non-procedural language to be compatible with a procedural programming language is more technical snobbery. |
|
|
BITAND does not exist in the 8i SQL Language Reference. There is a BITAND in 9i. There is neither BITOR nor BITXOR in any manual. BITAND is not even intelligent enough to know what data type it is returning. |
|
|
|
|
|
| 4 & 5. Oracle implements 1 standard language: ANSI standard SQL. PL/SQL is a procedural language extension to SQL, like Sybase's Transact SQL, and SQL*Plus is an ad-hoc query tool, not a language. the "set auto commit" is an adhoc query tool command; Sybase's "go" is not part of the ANSI SQL syntax. Your argument sounds like "PowerSoft commands don't work in Transact-SQL, and vice-versa." Of course they don't. |
|
|
Confession: Oracle implements 1 standard language but deems it unnecessary for its extensions to be compatible with one another. While both ANSI SQL and PL/SQL are embedded within SQL*Plus, SQL*Plus communicates "set autocommit" to ANSI SQL but not to PL/SQL. set autocommit is but one aggravating example. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
