Pointless debates on the finer points of naming your objects (moved from Combo Box Requery thread)

"onedaywhen" wrote in message
oups.com...

BruceM wrote:
Did you browse the whole 'naming conventions' aisle before making your
choice?

I picked one that seemed to be in common use

Perhaps it is or will be my downfall that I have never had much interest
in
"fitting in". My choices are logical and systematic, and they work for
me.
If they make me uncool in the eyes of some, so be it.

Is there anything more conventional than choosing the convention in
common use g?!

To quote from (I think) one of your earlier posts: "If you want to appear
as a 'serious' SQL database type person, take a look at what people do
outside of the Access ghetto". If people are going to evaluate my Access
abilities I hope they will do so based on what I do with the program. If
the convention in common use helps me be understood it has done what I ask
from a convention.

Maybe you are less of a rebel than you think ;-)

Oh, I can fit into a variety of situations. But as always, any choice will
be embraced by some and held at arm's length by others.
Interesting as always to engage in these exchanges with you.

Regards, Bruce

Jamie.

--

And, yes, I use the standard SQL terms column (in place of 'field'),
VIEW (in place of 'Query'), 'DECIMAL' (in place of 'Currency' g), a
relational/industry standard key (in place of 'autonumber' vbg) to
encourage others to look outside of the Access ghetto in the hope they
may benefit as I have.

Jamie / onedaywhen,

It looks to me like you are consistently overlooking a simple fact:
these here are ACCESS newsgroups, and people come here with their Access
questions... therefore, the replies are in Access terms. I'll accept,
for the sake of the argument, that "view" is correct, and "query" is
wrong, bad, filthy or whatever else you want it to be... even so, what
makes you so confident that the poster of a question will actually know
what you mean by "view"? How can you be so sure they won't be further
confused instead?

I truly admire the depth of your knowledge of SQL, which is exactly why
I hate to see your energy wasted on pointless arguments. I suppose you
must be enjoying this more than actually helping others!

Nikos

Nikos Yannacopoulos wrote:
It looks to me like you are consistently overlooking a simple fact:
these here are ACCESS newsgroups, and people come here with their Access
questions... therefore, the replies are in Access terms. I'll accept,
for the sake of the argument, that "view" is correct, and "query" is
wrong, bad, filthy or whatever else you want it to be...

I'll settle for 'non-standard'.

even so, what
makes you so confident that the poster of a question will actually know
what you mean by "view"? How can you be so sure they won't be further
confused instead?

I get your point. I'm pretty sure that when I use the term 'view' I
usually say 'Query', 'query object' or similar.

Access-specific terms can similarly be confusing for someone thinking
in standard SQL terms e.g. a 'delete query' would be an oyxmoron.

Surely as a community we can change the prevailing conventions and
bring terminology closer in line with that of the wider SQL world. In
the long run that would reduce confusion, I think.

To use (yet another) example, years ago I was sent on an elementary
Access course. The tutor was trying to teach about relationships 1:1,
1:m and m:m. I came out utterly confused, not knowing whether this
terminology applied to Query objects or Table objects or what. I didn't
use Access after the course and promptly forgot everything. When I
later started using SQL on another platform I quickly encountered
primary keys and foreign keys, of course, and it suddenly struck me
that this is what that tutor had meant! So for me, the SQL syntax made
sense and the Access approach did not. I figure there's got to be
others like me out there who are confused by the Access conventions but
would benefit from seeing the bigger picture; also lots of people for
whom it would be overwhelming, I guess.

I hate to see your energy wasted on pointless arguments

Touché g! I'm only as bad as everyone else posting to a thread with
the phrase 'pointless debate' in the subject line ;-)

Jamie.

--

"onedaywhen" wrote in message
ups.com...

Nikos Yannacopoulos wrote:
It looks to me like you are consistently overlooking a simple fact:
these here are ACCESS newsgroups, and people come here with their Access
questions... therefore, the replies are in Access terms. I'll accept,
for the sake of the argument, that "view" is correct, and "query" is
wrong, bad, filthy or whatever else you want it to be...

I'll settle for 'non-standard'.

even so, what
makes you so confident that the poster of a question will actually know
what you mean by "view"? How can you be so sure they won't be further
confused instead?

I get your point. I'm pretty sure that when I use the term 'view' I
usually say 'Query', 'query object' or similar.

The Access term is widely understood in an Access newsgroup.

Access-specific terms can similarly be confusing for someone thinking
in standard SQL terms e.g. a 'delete query' would be an oyxmoron.

Those people probably won't come to an Access newsgroup.

Surely as a community we can change the prevailing conventions and
bring terminology closer in line with that of the wider SQL world. In
the long run that would reduce confusion, I think.

Most people come here to learn about solving specific problems, and do not
care about the world outside of Access. While you may be correct about
using terminology that is in wide usage, most people posting answers here
probably do not wish to add a terminology tutorial to their responses, nor
are those posting questions likely to be interested in such instruction.

To use (yet another) example, years ago I was sent on an elementary
Access course. The tutor was trying to teach about relationships 1:1,
1:m and m:m. I came out utterly confused, not knowing whether this
terminology applied to Query objects or Table objects or what. I didn't
use Access after the course and promptly forgot everything. When I
later started using SQL on another platform I quickly encountered
primary keys and foreign keys, of course, and it suddenly struck me
that this is what that tutor had meant! So for me, the SQL syntax made
sense and the Access approach did not. I figure there's got to be
others like me out there who are confused by the Access conventions but
would benefit from seeing the bigger picture; also lots of people for
whom it would be overwhelming, I guess.

The problem was, of course, with the instructor. I am aware of your disdain
for Access, but an instructor's competence or lack thereof is not a
reflection of the software. A friend of mine does development work with
Filemaker. He is similarly disdainful of Access (and all things Microsoft),
but I hear about his struggles with problems that could easily be solved
with an After Update event or something of the sort. Still, he won't even
consider any possibility other than that Access is at the bottom of the
database scrap heap.

I hate to see your energy wasted on pointless arguments

Touché g! I'm only as bad as everyone else posting to a thread with
the phrase 'pointless debate' in the subject line ;-)

Yes, quite a number of us like to join the fray, don't we?

Jamie.

--

While what you say is true, giving it SOME prefix ensures that any table
that are unrelated to anything else at least get lumped together. I
personally find that easier than having them all scattered about when
looking at an alphabetical list. To each his or her own, though.



Rob

"onedaywhen" wrote in message
oups.com...

Robert Morley wrote:
Like I said, for myself, I don't generally stick to simply "tbl" or "vw"
or
whatever unless there's no other logical prefix

He's a idea for you: if there is no *logical* prefix (i.e. the table's
name already conveys meaning) then don't use a prefix that conveys its
*physical* implementation. At best it's redundant, worse it's mixing
logical and physical models.

Jamie.

--

I'll try again. My inline replies did not appear as such.

"BruceM" wrote in message
...

"onedaywhen" wrote in message
ups.com...

Nikos Yannacopoulos wrote:
It looks to me like you are consistently overlooking a simple fact:
these here are ACCESS newsgroups, and people come here with their Access
questions... therefore, the replies are in Access terms. I'll accept,
for the sake of the argument, that "view" is correct, and "query" is
wrong, bad, filthy or whatever else you want it to be...

I'll settle for 'non-standard'.

even so, what
makes you so confident that the poster of a question will actually know
what you mean by "view"? How can you be so sure they won't be further
confused instead?

I get your point. I'm pretty sure that when I use the term 'view' I
usually say 'Query', 'query object' or similar.

The Access term is widely understood in an Access newsgroup.

Access-specific terms can similarly be confusing for someone thinking
in standard SQL terms e.g. a 'delete query' would be an oyxmoron.

Those people probably won't come to an Access newsgroup.

Surely as a community we can change the prevailing conventions and
bring terminology closer in line with that of the wider SQL world. In
the long run that would reduce confusion, I think.

Most people come here to learn about solving specific problems, and do not
care about the world outside of Access. While you may be correct about
using terminology that is in wide usage, most people posting answers here
probably do not wish to add a terminology tutorial to their responses, nor
are those posting questions likely to be interested in such instruction.

To use (yet another) example, years ago I was sent on an elementary
Access course. The tutor was trying to teach about relationships 1:1,
1:m and m:m. I came out utterly confused, not knowing whether this
terminology applied to Query objects or Table objects or what. I didn't
use Access after the course and promptly forgot everything. When I
later started using SQL on another platform I quickly encountered
primary keys and foreign keys, of course, and it suddenly struck me
that this is what that tutor had meant! So for me, the SQL syntax made
sense and the Access approach did not. I figure there's got to be
others like me out there who are confused by the Access conventions but
would benefit from seeing the bigger picture; also lots of people for
whom it would be overwhelming, I guess.

The problem was, of course, with the instructor. I am aware of your disdain
for Access, but an instructor's competence or lack thereof is not a
reflection of the software. A friend of mine does development work with
Filemaker. He is similarly disdainful of Access (and all things Microsoft),
but I hear about his struggles with problems that could easily be solved
with an After Update event or something of the sort. Still, he won't even
consider any possibility other than that Access is at the bottom of the
database scrap heap.

I hate to see your energy wasted on pointless arguments

Touché g! I'm only as bad as everyone else posting to a thread with
the phrase 'pointless debate' in the subject line ;-)

Yes, quite a number of us like to join the fray, don't we?

Jamie.

--

Those people probably won't come to an Access newsgroup.

While I can hardly argue the point that this is an Access newsgroup ("like,
duh!" a la stereotypical teenage girl), one of the groups that this is
being posted to is also geared towards ADP and SQL Server, and so is likely
to attract at least a few so-called "real" database programmers who are
"just trying to help the poor misguided souls who seem to think that Access
is actually worth mentioning".

Typically, the poor misguided souls who seem to think that they're using a
"real" database system and Access users are not fall into one of two
categories: those who believe that Access is not as robust as insert
Enterprise-level system here, and those who have an unreasoning prejudice
against anything that isn't their chosen system.

Now, the former group certainly has a point. Access is not as robust of a
back-end as SQL Server (or Oracle or whatever else) is. I know it may
violate your preconceived notions, but not every database needs to be run on
an enterprise-level DBMS. Access is meant to create small, portable
databases on a local computer, or maybe with replication under a limited set
of circumstances, and it does that very well. And as a front-end, frankly,
I've yet to see its match. .NET may give you a lot more programming
options, and make the programming tier very powerful and easy to write, but
have you honestly ever tried designing a form with it? GODS what a
nightmare!

And as to the latter group, there's nothing we can do about them short of
chaining them to a desk with only Access available and forcing them to
actually USE it for more than a few hours and to actually learn how it works
and what it's capable of...not to mention forcing them into learning a
different way of thinking that doesn't involve command-line interfaces for
half the work they do. (Why am I reminded of Linux users?)

Alright, so much of the above is fairly prejudicial, but honestly people,
these are the attitudes you're projecting...why SHOULDN'T I poke fun at you?


Rob

Thanks for the link. I have been away from the programming front line for a
while. When I left I felt all alone in my views to the extent that I felt
inferior when contesting programmers writing "Hungarian".
Now I am not only not alone, but have learned something too.

David F. Cox

"Tim Ferguson" wrote in message
...
"Robert Morley" wrote in
:

And while "tbl" itself may have first appeared in a Smart Access
article in 1993, as I said, Hungarian notation itself pre-dates that.
As I said, Simonyi K roly (aka Charles Simonyi) did indeed work at
Microsoft, but he started Hungarian Notation back when he was working
for Xerox.

For a good description of the history of "systems Hungarian" and its
misapplication see Joel on Softwa

http://www.joelonsoftware.com/articles/Wrong.html

Tim F

Robert Morley wrote:
I currently [have a] view called "tblPreferences",

Until now I considered the 'tbl' prefix to merely redundant, other than
to identify an Access designer. Thanks to this usage example, I now see
it is a potential be a hindrance i.e. when you change your base table
into a virtual table (VIEW/Query) you have to either find and change
the name in every reference in code or make everyone live with a
counterintuitive prefix and those people who claim they find the 'tbl'
to be helpful are going to be really confused/annoyed g.

If that doesn't convince you that the 'tbl' prefix is to be avoided I'm
not sure what will.

Actually, there is something else nobody has mention AFAIK and that is
ISO 11179-5 'Naming and Identification Principles for Data Elements'
- google it. I urge anyone follow the ISO naming convention and see
if you still think you need the 'tbl' prefix.

Readers of this thread may find this article interesting:

http://www.dbazine.com/db2/db2-disarticles/gulutzan5

"VBA programmers use a Hungarian-style convention (Leszynski/Reddick),
so tblEmployees is a normal name. [However,] SQL programmers have less
need for Hungarian Notation because they can get the type information
from the metadata tables. Data in relational databases -including
metadata - should be atomic and shouldn't be redundant...'This is the
year 2000; the '60s are over! Things like "str_firstname" or
"tblPayroll" are redundant.' -- Joe Celko"

Jamie.

--

"onedaywhen" wrote in message
ups.com...

Robert Morley wrote:
I currently [have a] view called "tblPreferences",

Until now I considered the 'tbl' prefix to merely redundant, other than
to identify an Access designer. Thanks to this usage example, I now see
it is a potential be a hindrance i.e. when you change your base table
into a virtual table (VIEW/Query) you have to either find and change
the name in every reference in code or make everyone live with a
counterintuitive prefix and those people who claim they find the 'tbl'
to be helpful are going to be really confused/annoyed g.

If that doesn't convince you that the 'tbl' prefix is to be avoided I'm
not sure what will.

So you don't need to change the name if you switch from a table to a query,
but what if you change from one query to another? Also, several queries
could be based on the same table. Which one has the same name as the table?
What names are the others given?


Actually, there is something else nobody has mention AFAIK and that is
ISO 11179-5 'Naming and Identification Principles for Data Elements'
- google it. I urge anyone follow the ISO naming convention and see
if you still think you need the 'tbl' prefix.

I tried the search. That ISO standard is about metadata, which I do not
claim to understand, but which is well beyond the interests of most people
posting questions here. In looking through some of your links I have seen
calls for separating all words by spaces, and for not using spaces at all;
for using uppercase, lowercase, and mixed case; for using singular and
plural; and so forth. There is an expert somewhere with 25 years experience
or whatever who no doubt disagrees with you. Who cares, unless you are both
on the same project? If I work on a project with several others, the
project leader will come up with a naming convention, which I will follow.
I don't need to agree, just to get the work done. If I am that project
leader some day, by then I will have refined my views on the subject.


Readers of this thread may find this article interesting:

http://www.dbazine.com/db2/db2-disarticles/gulutzan5

"VBA programmers use a Hungarian-style convention (Leszynski/Reddick),
so tblEmployees is a normal name. [However,] SQL programmers have less
need for Hungarian Notation because they can get the type information
from the metadata tables. Data in relational databases -including
metadata - should be atomic and shouldn't be redundant...'This is the
year 2000; the '60s are over! Things like "str_firstname" or
"tblPayroll" are redundant.' -- Joe Celko"

Jamie.

Interesting as always.
Best regards.

--