Naming conventions

starkmann · #1 (**permalink**) 05-22-07, 15:06

I read the Access Ten Commandments today:
http://www.mvps.org/access/tencommandments.htm

forgive my noobish glow but, and recommendations on naming conventions? I have typically tried to use Nametbl, Nameqry, Namefrm, Namerpt and try to name things along the same lines, like Issue table for the primary table of my app, Issueqry for the query that brings together the lookups with the Issuetbl. Issuefrm would probably look at that and last Issuerpt for the big report with everything. Then as I add criteria I tend to add that to the name, like IssueOpenByUserrpt and so on.
Thoughts, crticisms, ideas?

I'm off to try an look up DB splitting now.

r937 · #2 (**permalink**) 05-22-07, 20:01

naming conventions are great, as is plainly evidenced by how many of them there are

if you have a naming convention, use it -- it will be a great comfort to you if you have to maintain your own code, and it might even help someone else if they have to maintain your code after you're gone

starkmann · #3 (**permalink**) 05-23-07, 10:38

Fair enough. So 'almost' anything works as long as you stick to it like glue, eh.

blindman · #4 (**permalink**) 05-23-07, 10:58

No spaces in object names.
Use CamelBackStyle rather than underscore_style.
Don't use object type prefixes such as "sp", "tbl", or whatever.
Eschew Acronyms.
Name your objects so that your SQL statements read like sentences.

starkmann · #5 (**permalink**) 05-23-07, 11:01

Quote:

Originally Posted by blindman

Name your objects so that your SQL statements read like sentences.

Oh, that one seems like a really good one. They're all good but that one is one I hadn't thought of, yet so obvious

msmeland · #6 (**permalink**) 05-23-07, 11:08

UnlessOfCourseYouAreParticuallyVerboseAndHaveATend ancyToOverexplainEverything.

starkmann · #7 (**permalink**) 05-23-07, 11:12

Quote:

Originally Posted by msmeland

UnlessOfCourseYouAreParticuallyVerboseAndHaveATend ancyToOverexplainEverything.

IAmGuiltyOfThatPrettyOften

r937 · #8 (**permalink**) 05-23-07, 11:40

Quote:

Originally Posted by starkmann

...as long as you stick to it like glue, eh.

no way

you want to be able to unstick yourself from it painlessly, should it turn out, in retrospect, to be silly

you know, like naming all your tables with 'tbl' as the first three characters

starkmann · #9 (**permalink**) 05-24-07, 07:07

stupid question but a couple of you mentioned not naming your items with a prefix. I don't but why is that so bad? You have to read four more characters to see what you are talking about but is there something more I am missing?

r937 · #10 (**permalink**) 05-24-07, 07:31

"nounParis prepIn artThe nounSpring"

the prefixes sure make it easier to read, don't they

props to Joe Celko

starkmann · #11 (**permalink**) 05-24-07, 07:49

lol fair play there.

That guy has a cool site w/ the SQL puzzles and all.Bookmarked.

certus · #12 (**permalink**) 05-24-07, 20:21

There is a naming convention by the International Standards Organization. Check out 11179-5 under ISO 11179

starkmann · #13 (**permalink**) 05-24-07, 21:23

now that is really cool. I have to admit, I have basically skimmed at this point but I want to come back to it. Most of what I have seen is pretty common sense but with a little structure thrown in.

sco08y · #14 (**permalink**) 05-28-07, 23:10

Quote:

Originally Posted by starkmann

stupid question but a couple of you mentioned not naming your items with a prefix. I don't but why is that so bad? You have to read four more characters to see what you are talking about but is there something more I am missing?

In SQL it really doesn't tell you much. Table names can only go in certain places, likewise with attribute names. That's the benefit of the complex syntax.

The practice probably came from C programmers. In C there's no way to tell if a variable is a "long" or a "short" integer and you can get into all sorts of trouble if you get them mixed up. And C allows you to have global variables strewn all over your project.

SQL can have the same problem, especially since CHAR(40) is a different type than CHAR(30), but it's mitigated to a large extent because all the type definitions being in the schema. You can still run into problems with temporary variables in triggered procedures, but it's nowhere near as bad as C.

I do use prefixes in one case: sometimes I group sets of related columns when it's a particularly wide table. In this case, it makes sense, to me at least, to deliniate these groups with prefixes. You can also plan ahead by creating queries that split the table up for you, e.g.

Code:

CREATE TABLE LotsOfColumns (
  primaryKey INTEGER PRIMARY KEY,
  namFirstName CHAR(),
  namLastName CHAR(),
  homStreet CHAR(),
  homCity CHAR(),
  homZIP CHAR(),
  wrkStreet CHAR(),
  wrkCity CHAR(),
  wrkZIP CHAR()
);

CREATE VIEW Names AS
SELECT primaryKey, namFirstName as firstName, namLastName as LastName
FROM LotsOfColumns;

CREATE VIEW  HomeAddys AS
SELECT primaryKey, homStreet as street, homCity as city, homZIP as ZIP
FROM LotsOfColumns;

gvee · #15 (**permalink**) 05-29-07, 04:28

Just another ingredient in the pot (since the thread is entitled "Naming conventions, here's another for you!) ...
I unfortunately have to program in FoxPro a fair amount and the naming conventions in there have to be one of it's only good features