Fabricio Araujo wrote:

> On Sun, 20 Mar 2005 11:08:41 +0100, Kjell Rilbe wrote:
> It's my case also, my native tongue is Portuguese. Is very rich in
> various types of accents. And no, I don't use quoted identifiers with
> accents
> or mixed case.

Good for you that it's rich in *accents*. But in Swedish we happen to
have letters not in ASCII that simply aren't accented variants of ASCII
characters - they're completely different letters: ÅÄÖ. What do you
suggest I do with them? Removing the ring in Å doesn't simply remove an
accent - it alters the letter into a completely different one. I might
as well replace all O:s with A:s. Nice.

Furthermare, in Swedish V and W are semantically identical. Yes
identical. In every aspect. Sa vhy dan't I just ga ahead and replace all
W:s with V. That vauld be very nice, vauldn't it?

>>In your examples, you've apparently chosen not to translate the words to
>>English but simply strip them of accents and convert them to uppercase.
>
> Yes. Works like a charm. And without the hassles of quoted identifiers.
> So I can query it as:
>
> select * from Clientes
> select * from ClIeNtEs
> Select * from clientes
> Select * from CLIENTES
> etc.
> etc.
> etc.
> All of them are valid queries...

Yes, but they will be in future too, since you didn't quote the
identifiers. And in fact I think it would be better if they were *not*
valid queries. If the column is called clIEnTes that's what it should be
called. Everywhere. And I would hang the one who chose that stupid name.

>>For example, in Swedish "hår" means hair
>>and "har" mean "has".
>
> Here the cases where it would create such a confusion
> is veeeeeeery litle. And even in that cases, I can create a good
> name without letter decoration, accents or obligation to follow
> a determined case.

That was a very self-centered statement. You seem to be saying that
since using only ASCII works for you and your native language, the same
should be forced upon everybody else. Very neat. Thanks a whole bunch!!

I repeat: it does *not* work in all languages. In fact I think it's safe
to say that it does *not* work in most languages.

> Confusion? Confusion is your boss saying the SP doesn't work and
> his program is not working after the request he done - change the
> name of return field... Because I commited a typo error, a space more
> where is not the place. Or in the middle I missed the case of one
> letter.

So you can misspell case sensitive and national characters but never
misspell upper-case ASCII? Strange.

> If the identifier is not quoted I had not to pass 2 hours seeking
> the code to realise of that cursed blank space - because the returning
> field will work.
> Quoted identifiers is just trouble, rope to hang-on yourself.
> I run from it like the plague.

So, don't use them. Noone's forcing you to. But for those of us who see
the benefits, they should enable us to use all characters in our
identifiers. Also, with quotes you should be able to spot that extra
space pretty easily since it would appear inside quotes (otherwise it
wouldn't matter anyway).

>>The simplest way of doing this would be for the developer to use the
>>word/name he really wants, without conversion.
>
> In theory, maybe. In my experience, however, is just only a
> infinite source of headaches.

In the current state of things, with poor support for quoted identifiers
in client tools, middle tiers, db engines, etc. yes, it does cause
headaches. But that's not a reason not to move forward. That would be
like saying "Since support for IP v6 is lacking in many places we should
drop it". Very bright indeed.

> Keep it simple. Case and accent insensitive code is simple.
> Simple to read. Simple to maintain. Simple to understand.
> Do not induce error on new DBAs.

I don't agree. Mixed case is easier to read. Otherwise, why would we use
lower-case in books or in fact anywhere at all? Which one of the
following two paragraphs do you find easier to read?

THIS THREAD IS BECOMING RATHER LONG NOW, BUT I GUESS THAT DOESN'T MATTER
BECAUSE IT'S AN IMPORTANT AND INTERESTING TOPIC.

This thread is becoming rather long now, but I guess that doesn't matter
because it's an important and interesting topic.

The fact is that, in general, lowercase is easier to read than
uppercase. Mixed case allows us to use natural language grammatical
rules in our identifiers, which will allow us to use our natural
language skills to read and interpret them. These are skills we've
obtained in early childhood and no matter how long you use SQL, you
can't beat that.

> It's so simple that don't cause trouble even when you mix
> the case on the same query...

Why would I use different case in different places for the same thing?
And it's not like it's very difficult to test either. Furthermore, tools
are becoming more and more intelligent. With code completion in SQL
editors mixed case and national characters might not even bother you
anymore.

Also, in a Japanese application, used only in Japan and only by Japanese
people and developed by Japanese developers, what on earth would be
gained by forcing them to use ASCII identifiers?

Sorry, I just don't get it.

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64