Re: Another angle on this....

damorgan <dan.morgan_at_ci.seattle.wa.us> wrote in message news:<3C7144EB.7CA04F3A_at_ci.seattle.wa.us>...
> My comments, barbs, interspersed below.
>
> Daniel Morgan
>
>
>
> Tom McClelland wrote:
>
> > Your points are valid, I don't contest them. However as someone coming
> > from SQL Server to Oracle I have faced the following significant (to
> > me) irritations:
> >
> > 1. Empty strings turned into nulls. Empty strings per se are not
> > supported
>
> What's your point? Those going from Oracle to SQL Server can complain
> about the exact opposite.

No they can't, those going from SQL Server to Oracle acquire the remarkable ability to distinguish between blank values and unknown values. They aren't required to use it. To me there is a big difference between someone not having a middle name and someone's middle name being unknown.
> So they are different ... so what? Did you think
This is not merely a difference. It is a bug in the way Oracle treats blank strings. I don't understand how you can defend it. I can't include a blank field in a primary key, ever, in Oracle. I can't get sensible results from select * from table where field>"". You are defending the indefensible in your zeal to consider Oracle equal or superior in every way.
> Oracle was SQL Server with another company name on the CD? Do you think
> that everything Microsoft does is the "standard" to which everyone else
> must adhere?

No, there are lots of things that I like better about Oracle, and lots of inadequacies in SQL Server.
> Do you think that because you learned SQL Server first
> somehow that makes it better?

No. You are wrong. I didn't learn SQL Server first (though I did learn it before Oracle), and I don't think that it is better in every situation.
> Good grief. If I followed that logic I'd be
> whining about things being different than they were in Fortran IV.
You are fighting a straw man with this one. You've set me up as someone who thinks a particular way, and then you are knocking that way of thinking over. Nothing to do with me.

> >
> > 2. Quoted identifiers are case sensitive, just what you need...
>
> BFD

You'll have to explain that one to me.
>
> >
> > 3. No support for identity columns, instead requiring programmers to
> > create sequences and triggers to achieve effects that are trivial in
> > other databases
>
> Implementing a seqence takes 29 keystrokes. Count them ... 29 to create
> the sequence and add it to an insert statement. This is a lot of whining
> over 29 keystrokes.

It takes a lot more than that to duplicate the full functionality of an identity column. You need to study the difference more closely.

> But go the other way ... I'd like to see you make your
> identity column count backwards by every third number and reset itself
> after every 300 inserts.

But I've never needed to do anything like that in 20 years. I just want column identities. Its a common requirement, sensibly supplied by all other platforms that I've used.

>
> >
> > 4. No option to ignore case on indexes or character-string comparison
>
> BFD. It is that bloody painful to type UPPER()?
Of course not, but for it to be efficient you also have to create the upper case functional index too. These little details add to the pain of porting generic code. I need to go through all my code looking for places where this may be necessary.
>
> >
> > 5. No support for comparison operators in arithmetic expressions
>
> I'm not clear on what you mean by comparison operators. But I strongly
> suspect you are otally incorrect.

How do you suspect that I'm incorrect when you don't know what I'm talking about? What do you think it can do? Look at the definition of expressions in the BN diagrams, and you'll see the difference between the expressions permitted for comparisons and the expressions permitted for arithmetic operations. (unless of course like CASE this has been added, in which case I apologise)

>
> >
> > 6. No support for "Case" notation
>
> Wrong! I use CASE WHEN in much of what I write. Try RTFM.
I stand corrected. I didn't notice that this had appeared in 9i, due to my stupid inability to find the 9i manual pages on Oracle's website (thank you DStevens for the URL). I am also told that it works in at least some versions of 8i despite not apparently appearing in the documentation. Curious.
>
> >
> > 7. Bugs in the ODBC driver which (in my case) make CLOBS unusable, so
> > I have to rely on varchar2(4000)
>
> Try an ODBC driver from another company.
Which one do you recommend? It's Oracle's ODBC driver that I am using. I've got 2 CLOB bugs.
>
> > 8. Out-of-the-box retrieval of multi-record datasets at 1/40 the speed
> > of SQL Server in my (highly optimised) ODBC usage (SQLBindCol,
> > multi-record Chunked retrievals, etc)
>
> Then you don't have a clue what you are doing.
That told me, I'm an idiot. So sorry for troubling you.

I said, "Out of the box". My routines retrieve records at around 4000/second on 4 other platforms as they install out of the box (MSSQL,Sybase,MSAccess(!), and DB2), and around 100/second on Oracle. I am sure I am doing something very wrong, but despite posting detailed expositions of this problem in these forums no-one has managed to suggest what it might be beyond suggesting that I read books on tuning Oracle, in order to achieve the same performance that I get for free in 4 rival technologies.
>
> > I know that there are work-arounds for some of these "features". And I
> > understand that Oracle is a great tool for those wanting to store vast
> > quantities of data. A competitor to SQL Server for those just wanting
> > to store a few million records and have a thousands of transactions
> > per day, with less than 50 permanent users, it ain't, IMHO.
> >
> > Ducks back into large concrete bunker and dons flameproof suit <G>
> >
> > Regards
>
> What your list clearly indicates to me is that you are totally clueless as
> to what Oracle is.

Its not a database then? Damn.

> Let me give you the reverse complaint list. One for
> which there is no work-around in SQL Server.
>
> 1. No multiversioning.

Sadly in my ignorance I don't know what this is. In my other platforms I am presumably suffering because of its absence. You didn't name lots of other great features of Oracle, that I would love if it were the *only* platform that I were trying to develop against, eg materialised views, the ability to use a sub query where a table-name goes in a query without building a view first, function-based indexes, and many others. Lots of great features don't make a product perfect however, and my experience of porting to Oracle has been around 100 times more painful than the other ports of my product that I've done.
>
> Didn't need any others. That one is more than enough. When you figure out
> how to code around that in TransactSQL let Bill Gates know.
Why should I, I don't like Microsoft particularly above Oracle.
>
> BTW: When the developer of the Jet engine left Microsoft and started his
> own company two or three years back his database platform of choice was
> Oracle on Linux. I guess he didn't know as much about it as you.
>
> Daniel Morgan

Daniel, what's your problem? You seem very upset and defensive that I don't love Oracle as much as you do. Do you not think that at least some of my complaints could be legitimate criticisms? Received on Tue Feb 19 2002 - 02:40:10 CST