Oracle Response 5

Oracle's Response (5)

16. Push "Caps Lock", and the problem goes away. Another petty point.

Confession. The Oracle user must use capital letters to define all object names; otherwise, he will have problems later. Though a throwback to the 5-bit teletype days of the 1960s, this is the Oracle architecture. Therefore, do not use lower case or camel notation. For example, mytable or MyTable will get you into trouble. Under the covers, Oracle changes your names to uppercase. If you search the catalog for your tables using your intended names, whether via selects or via ODBC SQLTables function, you will not find them.

This incompatibility in Oracle grammar is between Oracle DDL and Oracle SQL, supposedly elements of the same language. At some expense, this problem has forced Engage Inc. to keep its cross-platform schema in upper case. Sybase and MS SQL Server users laugh at that , but Oracle forces the obsolete convention.

17. Pretty petty. See #4.

Confession: By default, Oracle does not allow a blank line in your SQL statement. A blank line, i.e., nothing, to Oracle, erases your last command. Given another attribute of Oracle which the empty set contains zero-length strings, we can now officially say , "In Oracle, nothing means something and something means nothing. "

18. This is again contradictory & inaccurate. "Oracle is incapable of dropping a table with only outgoing referential integrity constraints." contradicts "[To drop a child table] Just add "cascade constraints" to the drop statement." Sybase has had no ANSI standard integrity constraints for years, so criticizing Oracle's implementation is a bit amusing.

Confession. Oracle requires extra syntax "cascade constraints", even though it is not logical in order to drop a table. Because the extra syntax is not needed to carry out the operation, its presence is not logical. It contradicts the rules of computer language. Again, this requirement adds to Oracle's unpredictibility. In Oracle 8.0 and before, one could drop the childmost table without saying "cascade constraints." Newer versions added the requirement. Therefore to Oracle, a better Oracle is a more illogical Oracle.

Mr. Conway has brought up a couple of other things. First, I don't think Mr. Conway understands that a table with only outgoing RI constraints is synonymous with a childmost table. If a table has only outgoing constraints, then the table depends on others but no table depends on it. Therefore, the table is a childmost table. On the other hand, if a table has incoming constraints, then the table is parent to another, and thus is the not a child.

Secondly, Mr. Conway says that "Sybase has had no ANSI standard integrity constraints for years." That was true for about 5 years prior to 1994. Before 1994, Sybase implemented RI using triggers. At that time, Oracle itself had no trigger or stored procedure capability. In 1994 when Sybase introduced Sybase 10, Sybase added ANSI RI constraints. However, ANSI-style constraints were never necessary to enforce RI in Sybase, nor are they necessary today.

As a matter of fact, the inclusion of ANSI-style RI constraints in Sybase actually blemished Sybase's purity. I bet that Sybase marketing and technical staff fought over this. The ANSI RI constraint standard detracts from the mathematical possibilities and enforces a data model that is in some aspects not the real world. For examples, 1) why must a primary key not contain a null column? and 2) When you pick up a book, do you look for its index or for its keys? These requirements and view miss the mark. Sybase was reluctant to adopt it because they saw the error. Oracle, however, never saw the error in it.

19. More pettiness. If the table is empty, dropping and enabling RI is trivial and fast. Oracle has the ability to defer RI constraints on load, and disable RI with a single simple SQL statement. Does Sybase enforce declarative and referential integrity at all , or do you still have to code it all in stored procedures and pay the performance penalty for such a inefficient approach?

Confession: Oracle forces you disable RI constraints before truncating an empty table. A great example of an Oracle oxymoron that will cost your company thousands of dollars. Mr. Conway does not know how I discovered this. So let me tell the tale. I tried to write a script which truncates tables. I wrote the script such that it truncates tables in child to parent order--an order which guarantees never to violate RI constraints. The script failed with a syntax error. Then I had to find out why. My tables were empty, but why couldn't I truncate them? After the disgusting realization, a realization which even company Oracle fans were surprised, I had to write 100s of lines of code to disable and re-enable constraints though there was no need to disable them in the first place. Cost: $10,000. I am not talking about a single table with one constraint as Mr. Conway thinks. I am talking a script with 60 tables with 200 constraints

In DBPowerSuite, I wrote a program called psGTruncateTables which generates the code to truncate tables. It will do so for Oracle and MS SQL Server (which has a similar problem). It will do so for any ODBC data source, and it will do it for Sybase. It disables constraints, truncates the tables, then reenables the constraints. I was forced to write this program because of Oracle. I guess I am just being petty."

As for Sybase, Sybase is intelligent. It checks the RI before truncating a table. If the table is empty, there is no performance penalty. If the table is full and foreign keys depend on it, then Sybase checks. But one is generally not foolish enough in the first place to truncate a million row table whose rows are required by other tables. As for RI on loading, Sybase ignores RI in a bcp load.

Now the reader must remember. Like the drop command, Oracle added truncate table's illogical syntax requirement as a feature to 8i. We are supposed to consider this as an improvement.

20. Again, this is a basic security feature: the owner of the table owns all privileges on that table; no one else does. But what would Sybase know about security? How many national or international security evaluations does Sybase have? Answer: 0. Oracle has 14.

Confession: The system manager in Oracle cannot grant permission on an object to a user. If you can imagine root in UNIX not being able to do a chown or chgrp, then you can imagine Oracle. It is hard to believe, but it is true. Congratulations to Oracle for its 14 security evaluations. I guess a system is secure since not even the system manager can access it.

The problem comes when you need to write a migration script or any script that needs to access more than one schema at a time. In order to accomplish that, the script must log into the server at least once for each user. The script must first login as user A in order to grant B permission. Then the script must log out of A, and then log in as B. That way the script can write into B's schema. The more schemas you need access to, the more separate logins you must potentially perform. You will also experience problems creating a read-only view which reads another user's table even when you have read access to his tables. In the end, the lack of a proper system manager will require double the programming time. Your migration scripts will grow complicated and convolute to the point you don't even know who's doing what. In the end, you will swear. You will curse Oracle's concept of system manager, 14 security evaluations or not.



	© 2010 Talus Software. All Rights Reserved. Home \| Buy Software \| Privacy