Oracle's Response (9)
39. This is incorrect. See #28.
Mr. Conway is incorrect. Importing a file requires at least enough rollback space to handle the largest index in that file. As opposed to manually creating your own indexes using 'unrecoverable' and 'nologging' options, you have no control over how those indexes are defined in somebody else's exported file.
Go to Fractal Site
40. Again, this looks like poor database design. Are Sybase dbas always such poor database designers?
Mr. Conway doesn't understand the need to 'create clustered index' on an existing table. In Oracle terms, he doesn't see the need to turn a heap table into an indexed organized table.

In Sybase, say it takes 40 minutes to load 2 million rows into a table with a clustered index. In Oracle, it takes 20 hours to do the equivalent if it can do it at all. Since it takes too long in Oracle, the alternative is to first load the data into a heap table. The time for that is acceptable. After it's loaded, then turn the table into an index-organized table. But you cannot do that in Oracle. You cannot make an index-organized table from a heap table. The reverse is also true: You cannot turn an index-organized table into a heap table.

The goal of this exercise is to load data into an index-organized table without needing disk space equal to twice the size of the table (for the index-organized table itself and the corresponding heap table), and to do the operation in an acceptable time (less than 1 hour). But in Oracle, you are stuck with a loading problem. 20+ hours to load directly into an index-organized table is not acceptable. And creating a work heap table doubles your space requirement. You have a dilemma, but you do have an alternative. Unfortunately, it is what you wanted to avoid all along. You must use all non-clustered indexes. You cannot have an indexed-organized table. Your table must consume an extra index's worth of space, and must require an extra disk seek for every lookup. But there is a bright side! You have achieved Oracle's prime directive. You have needlessly hoarded resources.
Go to Oracle
41. This is basic discretionary access control security policy, which Sybase obviously does not implement. Creating synonyms (SQL generating SQL) is a no-brainer for a competent Oracle dba.
Confession. Oracle requires you to create thousands of synonyms due to lack of "dbo". Sybase doesn't implement synonyms for a simple reason. Sybase has a better solution. In Sybase, all the users of a database see dbo's schema as if it is their own. To access dbo's employee table, the user just specifies, "employee". Sybase does not require an owner qualifier.

That simple convenience is absent in Oracle. Every Oracle user must either specify the owner for every object in every script and piece of code, or the DBA must create a synonym for every common object for every user. The work, though a no-brainer, is stupendous If you have 1000 users and 1000 common objects, that's 1 MILLION synonym creations. That's 1 MILLION extra objects whose existence stems from a design deficiency. That's 1 MILLION extra objects that the competent DBA has to create and maintain. Competent or not, no one wants to deal with that.
42. This is incorrect. Oracle9i usernames cannot have a dot in them.
I hope not! I haven't tried this in 9i yet, but in 8i they certainly could. It was quite entertaining watching Oracle SQL*Plus allow this, then core dump later. The whole company got a kick out this one.
43. Synonyms are different than Sybase's implementation of a multitude of databases, no better or worse.
Confession: A fully qualified object name in Oracle is just owner.object, and he's proud of that. That feature is 2 magnitudes less flexible than Sybase (server.database.owner.object). Aside from the power, Sybase's form is easier to read and makes navigating among the data easier. Unlike Oracle, the Sybase user doesn't need to find the synonym--the needle in the haystack.
44. This is incorrect. Oracle9i stored procedures can return result sets (8i could as well).
Oracle's definition of result set is different than everyone else's. Mr. Conway is in the dark of what result sets really are. Like the concept of null, Oracle has perverted the definition. All of Oracle's followers have been deceived by the great Oracle. Oracle stored procedures do not return results sets as a Sybase or MS SQL Server programmer knows them. Oracle stored procedures return cursors. These cursors become available after the stored procedure runs. You must define and open each cursor to get the results. No one gets data via cursors if they can help it. It takes too much time to program.

Sybase and MS SQL Server return the real definition of result sets, not cursors. As a Sybase stored procedure runs, the client receives result sets. One row result set arrives for every select statement in the procedure. Just before the procedure ends, the procedure may send other types of result sets. The procedure may return parameter result sets, compute result sets, return value result set and others. The programmer does not use cursors to read the results,.

Do a google search on Oracle, ODBC and stored procedures. There are white papers devoted to the translation of Oracle's stored procedure cursors into result sets for ODBC.

Remember everybody. There is no "select x, y, z from t;" from inside an Oracle stored procedure; thus, Oracle cannot produce a result set. Think about what that does to the complexity of your programs. Think about the kludges Oracle is going to force you to do.
© 2010 Talus Software. All Rights Reserved.

Home | Buy Software | Privacy