Darren Duncan wrote:
At 9:44 AM +0100 2/1/06, Alexander Foken wrote:
You could slowly migrate your system, a first step would be to make
sure all table and column names match /^[A-Za-z][A-Za-z0-9_]+$/.
Next, move the tables and the business logic to a "real" database.
Then finally, get rid of ODBC drivers and Access on the clients and
switch to a web frontend using a native driver like DBD::Oracle or
DBD::Pg.
Any "real" database can use all of the same identifiers that Access
can, and in fact you can use any character at all in one. You just
bound them in double-quotes everywhere they are referenced, at least
with databases conforming to the SQL standard of delimited
identifiers; some products may use alternate delimiters.
Right. But using a restrictive set of characters for table and column
names makes things easier. "The column for the number of hours worked
for that day and that client, including phone support, but without
travel time" may be a perfectly valid and very speaking column name, but
"Hours_Worked" is shorter, easier to type, does not run easily into name
length limits, and has no need for quotes. I do not propose to use
stupid abbreviations like "hsw", but to use reasonably short and
readable names (two to three words), using only letters and digits and
the underscore instead of the space. In the original example,
"EMPLOYEE_NAME" instead of "EMPLOYEE NAME"
Chopping out the spaces and stuff is only crippling yourself. --
Darren Duncan
I don't want to remove spaces, I want to replace them with a character
that does not need quoting. Column and table names are identifiers for
the database and the programmer, not pretty and nice names for the end
user. Nice names and providing help is the job of the front end, not the
job of the database.
Alexander
--
Alexander Foken
mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
