If it would have been up to me to set the standards and defenintions, I would *_NEVER_* ever have allowed blanks^wnon-word characters in table(space)- and field- names.
I have just had the luck^wawful experience of having to convert a M$Access DB to Oracle. Table names as "Tabel leerlingen & verantw." and field names as "LW 34_18.w" were the M$ DB designer's regular choice.
I disagree, but of course that's just my opinion.
While it seems more un-natural to have delimited identifier names when we hand-code SQL (since identifiers are like program variable or routine names), they are a lot more natural if SQL is typically generated, and you consider the identifier names more like data than programming code.
And from the user's point of view, when they create databases using GUIs, the identifier names are data which they type in.
Or a better analogy is to compare identifier names to filesystem file names. It's quite normal to have file names with spaces or punctuation in them, is it not? Especially when we're using a GUI to create or access those files. These things follow the way humans think, rather than computers.
Even from a computer's point of view, there's inherantly no difference at all as to what characters an identifier contains; it only seems to matter when those identifiers are inside a SQL string that needs to be parsed, but after parsing the computer doesn't care at all.
The SQL standard itself also supports delimited identifiers (using "" by default, I think, but almost anything can be used as a delimiter), since/including SQL-1999, as do many database engines. According to the standard, delimited identifiers are case-sensitive. Non-delimited identifiers are not case sensitive, just like SQL keywords. Insensitive identifiers are equivalent to the same letters uppercased when made case-sensitive, as I understand it.
Also, if SQL is generated rather than hand-written, the difference is trivial.
-- Darren Duncan
