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

[Vayse]

programming style, they have now reverted completely, and prefixes are
AbsolutelyOut for anything based on the new versions of VisualStudio --
or should that be visualStudio?

I have to do a lot of vb.net work, and I find the new naming convention a
bit awkard. New MS articles insist on dropping the o for object, as
everything is an object now. And cls for class is gone as well, of course.
But there are still some 2003 and older articles amongst the help files,
where they have different naming conventions. But thats not too bad, its
easy enough to get used to.
My old way: Dim oClient as New clsClient
New way: Dim SalesClient as New Client
It does mean thinking of names though! Like having to use SalesClient in
this sample.

What really gets me is the names on forms. So instead of gridClients, its
now ClientsDataGridView. And then theres ClientNameTextBox. Its very hard to
get used to, after years of txtClientName!
In some ways it makes sense. All your Client objects are grouped together.
But I think I'll keep to the old ways in Access. Though I may not be able to
keep up two naming conventions for ever.
Diarmuid

 

[david epsom dot com dot au]

Furthermore, FORTRAN, the FORmula TRANslation language, was often
used for formulas, where i,j, and k were indexes to an Array. This
was a notation that predated computers.

We got the word 'array' from the same source: if FORTRAN had not
been used by engineers and mathematicians, we probably would have
had a 'table' instead, which is what we now call that construct
when we use Access to save it to disk and read it back again.

(david)

 

[david epsom dot com dot au]

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)

 

[david epsom dot com dot au]

BASIC won the war, and lost all the battles: .Net has adopted
all the features that made BASIC - fully memory managed string
class, interpreted library, single basic type, etc - dumped the
ideas like prefix notation that were only there to make up for
defects in the C language definition - and given us a new C
language with all the features they laughed at.

In a language that supports memory management and ByRef variables,
where the most difficult part of programming is not keeping track
of your indirection, stack pointers, and string space, it no
longer makes sense to put the syntax annotations in the high-
visibility space at the front of the variable name.

Now, after a long detour through C, we are back were we were
with Pascal: variable names refer to the logical content of
the variable, rather than the structure of the variable.

I still use postfix notation for variable types: name$, cost%
where it helps. There should be postfix annotations for all
types /where it matters/. Unfortunately, that is one place where
..Net is still caught in the 'real-programmer' fashion. They
can't use language-supported postfix notation because C didn't
do it that way, and because BASIC did.

Instead, when they need to note information about the structure
of the element, they are typing it out, COBOL style. And it's
not that I object to COBOL: I could do object-oriented
programming in COBOL, even though COBOL was not 'object-oriented',
and you can do postfix notation in .NET, even though the language
does not support it, but in the end, it's more efficient to
have language support for features like that rather than doing
it all your self.

(david)

 

[BruceM]

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

I picked one that seemed to be in common use, and turned my attention to the
program.

Of course. When I started dabbling in WordBasic, I used logical terms
for variable names; I was working in the office of the board of
directors and wore a blazer, slacks and smart shiny shoes to the
office.

I wanted to move into VBA software development so, to be taken
seriously by what I hoped would be my peers, I adopted the naming
convention lng- for Long Integer, str- for String, dtm- for Date, etc.
These prefixes did not add value for me personally: the variable name
told me how I was using it and hence conveyed the data type, the prefix
seemed to be redundant and jar.

When learning something new we tend to adopt methods used by those from whom
we learn. As it happens I learned from people who tended to use a
particular naming convention.

Luckily in my SQL career I took the 'standard SQL' path from day one
and never got into the whole 'tbl', 'fields' and other Access
conventions. When I first started using .NET I was very relieved that
the convention has moved away from data type prefixes to logical
variable names; I still use the prefixes in VBA, though sometimes I
can't be bothered and stick with the .NET convention. I was amused the
other day to see an MVP using camelCase for their Access column -
sorry, field - names <g>.

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.

Oh and today I'm wearing a t-shirt and jeans (because sometimes you
need to fit in) with walking boots (because sometimes you need to do
what makes practical sense).

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.

 

[BruceM]

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

 

[Nikos Yannacopoulos]

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

 

[BruceM]

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.

--

 

[Robert Morley]

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

 

[BruceM]

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

I'll settle for 'non-standard'.


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.

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?

 

[Robert Morley]

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

 

[aaron.kempf]

Robert;

don't ask questons; just do it

'standing on the shoulders of giants'

it is very useful; also when writing classes you start them with a C.

if you have standards like this; it is very very easy to automate
access if you follow standards like this.

 

[David F. Cox]

I have lived from A$ and I%, through deciding suffixes were a "bad thing"
and onto str_A and Int_I .

The word "fashion" comes to mind.

I now try to write my programs for those who are going to read them.

David F. Cox

 

[aaron.kempf]

this flexibility-- to bend the rules-- is a great feature not a symptom
of a problem

being able to call a view tbl is a great feature; it's a life saver--
you should only ever use it like once or twice a year.. but it's
definitely a great feature

you can't always predict how things are going to unfold

having a strict naming convention is a requirement not an afterthought

 

[BruceM]

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.

 

[Robert Morley]

Absolutely no question that this lead to problems, which (as I said) is why
I tend to avoid the "tbl" prefix.

Thanks to the wondrous concepts of n-tier development, however, the impacts
of changing the view name outside the database, however, are minimal. As I
said, I just haven't gotten around to it yet. (And due to the fact that the
database is in high demand right now, I probably won't get around to it
until Christmas.)



Rob

 

[BruceM]

If the logical name still stands, change the definition of the
query/view if it is more conducive to do so e.g. to point the first
query at the second query. If the logical meaning changes then you will
have to change the name in code anyhow; prefixes based on physical
attributes will neither help nor hinder.


Remember a query/view is a (virtual) table. Two tables cannot have the
same name.

My mistake. But what is your point about using a query instead of a table
in the code?

Choose names that differentiate their logical differences.

I do that, and will continue to do so.

I admit that
the differences can sometimes be so subtle to be tempted to resort to
using metadata (I'm thinking now about the kind of scenario where you
want to remove all permissions from the base table to be able to
control SQL DML via stored procedures ('parameterized query objects').

I use naming conventions because it's easier that way. I will agree that
for tables and queries a prefix may be redundant, but any naming scheme
follows certain rules.

The 'tbl' prefix is definitely metadata. The 'tbl' prefix is definitely
not recommended by the ISO standard.

ISO 11179 is listed thus: Information Technology -- Metadata Registries
(MDR). That was my point about the ISO standard.

You could be right that people in these groups are not interested in
creating data dictionaries but I think it is in their interests to do
so and I think the ISO 11179 can help, even if you decided to deviate
from that prescribed (as Joe Celko does for his naming convention
descibed in his excellent book, 'SQL Programming Style').

Ah, those people who don't know what's good for them. Pesky bunch, aren't
we?
;-)

Jamie.

Best regards.

 

[david epsom dot com dot au]

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 does identify an Access designer.

To an Access designer the information is not redundant.

The information would be redundant if there were no
difference between 'query' views and 'table' views.

The fact that there is a difference between 'table' views
and 'query' views is a failure to implement the relational
model in Access. I note that this is a common failure in
'relational' database systems.

It's a fact that the 'tables' and 'queries' are listed
on separate tabs in Access. 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.

But given that SQL Server also lists 'tables' and 'views'
separately, what is different about Access that makes the
metadata annotation useful to Access programmers, but not
useful to SQL Server DBAs?

Well 'duh': Access programmers use the GUI for reference
when building forms, reports and queries. If you aren't
using the GUI as your primary reference, the tab location
of the view is not relevant to your naming convention.

What about Joe Celko? If I may quote:
"Please post DDL, so that people do not have to guess"
Obviously, Joe C is not referencing the Access GUI for
metadata, so in his case, using 'tbl' and 'qry' annotations
would be redundant.

(david).

 

[david epsom dot com dot au]

"I now see it is a potential be a hindrance"

A potential hindrance for people posting DDL in
Access groups?

No, we are also talking about the use of naming
conventions in building databases.

Once we move away from the news groups, the fact
remains that annotated names have a functional
value for Access programmers, not seen by other
DBA's, and are not merely a social marker.

The naming convention does have some drawbacks:
for other kinds of users it might only have
drawbacks, but for Access programmers it is an
indication that they understand their tool, not
an indication that they fail to understand other
tools.

Incidently, for an Access programmer, there are
two conflicting naming criteris: (1) The names
should sort logicaly in the database window,
(2) the names should be short enough to display
intelligently in the default QBE design view.

Criteria 1 encourages coding repetitive information
at the start of the name, so that related views
group together:
Criteria 2 encourages coding repetitive information
at the end of the name, so that differentiating
information is easily visible in the QBE design
window.

MS made a first attempt to handle these problems
with the 'Groups' tab in Access 2000, but in
practice it's always difficult: Note how the
MS file system has progressed from 'shortcuts'
to 'hard links' to 'soft links', which is an
attempt to address a similar problem.

(david)

 

[david epsom dot com dot au]

I have more than 4000 views. I am fairly intimate with
the schema, but I still don't remember all of the names:
I know MM_Audit and DP_Contract, but am I looking for
SystemUsers, or Users?

If I know that all of my family live in the big tower
with 100 apartments, and you know that all your family
live in a 4000 bed dormitory, I will have less trouble
finding the kids after finding the correct apartment.

But the apartment number will be very helpful.

All you have to do is stand in the middle of the room
and look around. Once you've found your wife, you will
have to stand in the middle of the room and look for
your kids: are they over by the TV? Are they over by
the coffee?

The fact that all my family are all on the 'same tab'
doesn't make the tab identifier less helpful: the tab
identifier is helpful because there are multiple tabs,
and the multiple tabs are in use.

If there were no functional difference between queries
and tables, there would be no value to the annotation.
But in Access there is a functional difference, and there
is a functional value to the Access programmer.

One of the original ideas of relational database design
was to eliminate the functional difference between
tables and queries, so that a view could be inverted
without cost. In that sense, Access is fairly successful.
(If it was totally successful, OLAP cubes would not be
required)

But in the GUI it retains the functional distinction
between queries and tables, and that has implications
for useful naming conventions.

(david)