At 9:30 AM +1100 2/2/06, Ron Savage wrote:
On Wed, 01 Feb 2006 13:36:41 +0100, Alexander Foken wrote:
Right. But using a restrictive set of characters for table and
column names makes things easier. "The column for the number of
Just as I raved about back in 2003 :-):
Now, I understand the arguments for limiting names to certain
characters that don't need delimiting, and that's fine for some
contexts. But I also wanted to make clear that there are some
contexts where such limiting is counter productive, and so it is good
for database engines to be flexible, regardless of how users decide
to design databases.
I considered it important to be able to support spaces and other
arbitrary characters, because I see this support as making things
easier to use from a non-programming user's point of view.
Say we're making a consumer database application that is of the
point-and-click GUI variety and has little to no structural
abstraction (such as with Filemaker Pro or MS Access or perhaps
Oracle Forms), where users can define their own tables and columns
and such in the same ways they can define category names or folder or
file names, where they just type the name into a text input box.
These users would never see anything resembling programming code,
such as SQL, but just know they're making a database.
It would be quite natural for such users to make identifiers like
'Person' and 'Home Address' and 'Home Telephone' and 'Work Telephone'
and so on; it isn't natural for them to say 'Home_Telephone' and such.
So if we're making this consumer application and it is implemented on
top of a generic SQL database, and assuming there is very little
abstraction involved, we would probably be generating SQL code that
lines up the names the users chose with identical table and column
and such names, including the spaces. There would be no translation
necessary since the identifiers in the database are the same as what
the users see.
Sure, we could impose naming restrictions on the users, so we can
generate SQL without delimited identifiers, but then that would be
making things more difficult for the users to make it easier for
ourselves. And it isn't even that much extra work to support this,
or it may be less work.
From users' point of view, I see allowing this flexability to be like
allowing them to name their file system files anything they want, and
often they like to put spaces in file names. The users aren't
creating programming code, there creating boxes to put their data in,
conceptually not far off from folders and files.
I'm also not suggesting that identifiers have to be arbitrarily long,
like whole sentences; rather, just about the same lengths as are
valid for folder or file names; just they should be allowed to
contain spaces and such.
-- Darren Duncan
