Nuno, I wasn't going to reply in detail because many of your points are
either correct or similar to ones that Daniel made that I have replied at
tedious length to.... but your detailed thoughts deserve their own response.
> >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.
> By RDBMS theory definition, a composite PK can NOT have a null value
> in a column. But you can emulate the functionality of SS very easily
> nowadays. In a way, Oracle is doing the "correct, textbook" thing.
> If that is handy or not is debatable. then again, what are standards
> for if nobody follows them?
No No No, I don't want nulls in PK, just a blank string. ITS NOT THE SAME
THING EXCEPT IN ORACLE (how rude to shout). Also not just SS but DB2, Sybase
et al. And I don't mind blank strings at the end of collation sequences, but
I don't want 'where somefield>""' to return no records because the "" gets
mangled into null. Not helpful. Once they disasterously mangled "" into null
everything that follows from that is the "correct textbook" thing.
>
> >> > 2. Quoted identifiers are case sensitive, just what you need...
>
> I must admit I don't follow your initial problem? Why is it what I
> need? Don't really see that as a problem. Again, the SQL standard
> says: if you quote, you get what you asked for. What's wrong with
> that?
Its just inconvenient for me, when porting, nothing else. Developing under
Oracle I wouldn't give a toss about this. My code quotes everywhere, for
safety, and in some places the case wasn't right, as you might expect as it
never occured to me that the case of a db identifier could be sensitive.
> >> >
> >> > 4. No option to ignore case on indexes or character-string comparison
>
> Use function-based indexes. Also, think about exactly how can SS
> implement "case-insensitive" indexes. Isn't it losing something?
> Well, with Oracle you now lose nothing. Since 8i.
I'm not losing anything that I want. I have never once in my life been
annoyed by retrieving data of the wrong case.
> >> >
> >> > 5. No support for comparison operators in arithmetic expressions
>
> to do exactly what? How can you have a comparison operator in an
> arithmetic expression? You either have a comparison operator in a
> logical expression or an arithmetic operator in an arithmetic
> expression. What am I missing here? Unless we want to _assume_ that
> TRUE is = arithmetic 1 and False = arithmetic 0, which is absolutely
> flawed to start with!
Best tell the creators of most serious programming languages and db syntaxes
that has ever existed that. I'm not interested in the value of TRUE, except
that its not 0, False is 0, everywhere. Hence
decode(periodnumber>someperiod,0,0,SomeaccountingValue) would have been a
useful fix for the perceived absence of CASE. Supporting arithmetic use of
logical operators is actually easier than preventing it. Someone in Oracle
did extra work to stop it from happening. Its the first db or programming
language where I've ever noticed this, though I'm sure others will have made
the error too.<G>
> >I stand corrected. I didn't notice that this had appeared in 9i, due
>
> It's in 8i as well. But only for SQL (no PL/SQL). It's in the doco
> too. I can confirm for sure in 8.1.6 and 8.1.7, the two 8i versions
> I'm well familiar with.
If its not in PL/SQL then thats how I made my mistake. I tested my reporting
views by creating them in PL/SQL in 9i and couldn't get CASE to work.
>
> >>
> >> > 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)
>
> Hmmmm, I'd like to "scan" that problem in detail, but prolly no time
> to do it. Strongly suspect that whatever you can do in DB2 or SS in
> terms of performance you can also in Oracle. However you may have to
> twiddle with the default. In that respect, I agree with your
> frustration completely!
This is the only problem that was still a problem, not a whining gripe about
something that I've eventually got to grips with. And its still a problem.
Damn.
>
> >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
>
> Hehehe! How about the sub-query as the column? I like that one!
>
> >some of my complaints could be legitimate criticisms?
>
> IMHO, some are. I've had a bone with Oracle about some of them for
> ages, but unfortunately most people I talk to think I'm somehow
> *undermining* Oracle or whatever. Nothing could be more remote, but
> what the heck I stopped caring about that years ago...
I'm not undermining Oracle either. My dream would be some expert showing me
that all my assumptions are wrong and all these problems dropping away.
>
>
> Cheers
> Nuno Souto
> nsouto_at_optushome.com.au.nospam
Received on Wed Feb 20 2002 - 14:46:17 CST
