It's a fact that the 'tables' and 'queries' are listed
on separate tabs. If they were all listed together, it
would make sense to totally drop the annotation: but
I share multiple databases with other developers, and
when you are looking for a view, you need to know if you
are in the wrong database, or just on the wrong page.

The terms 'field' and 'record' encourage me to think
in terms of card databases. I know that they were also
applied to file systems and sequential processing, but
they were never any more relevant there than they are
with SQL databases and set-based theory. Even the word
'file' was a barrier to people being introduced to 'file
systems': the concepts were too dissimilar to be helpful.
If they don't help with SQL, it's not because they are
bound to file/tape concepts: they never really worked
there either.

However, to be honest, you can use any sound to refer
to any concept. The real problem is that people use
language to define social groups, and social groups are
defined just as much by who you can exclude as by who
you include.

(david)




"Jamie Collins" wrote in message
oups.com...

Robert Morley wrote:
"tbl" for tables, "vw" for views

Another thought. Could using prefixes encourage the wrong mental model?
For example, using 'tbl' and 'vw' differentiates between a table and a
view (or 'qry for Query, to use the Access conventions). The difference
is physical whereas logically a view is a (virtual) table so why
differentiate at all? If I say SELECT last_name FROM Customers, why
would I care whether the table was virtual or otherwise? What value
does the prefix add?

Likewise the terms 'field' and 'record' which still prevail in the
Access world, rather than the respective terms 'column' and 'row'
preferred in the wider SQL world. Do these terms really encourage
people to think in terms file systems and sequential processing rather
than SQL databases and a set-based mental model?

Jamie.

--