If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Your Opinion on Design Question
I know this may be a hard concept for you, but simply put, tables are
collections of objects and queries have actions. So Vendors would be a table, Vendor a record in that table and NewVendors a query. John... Visio MVP "Steve" wrote in message m... If you are such a "truly competent database professional", answer this: Vendor appears in some VBA code, is Vendor a table or query? Steve "Michael Gramelspacher" wrote in message ... On Sun, 23 Nov 2008 17:13:27 -0700, "Tony Toews [MVP]" wrote: "Steve" wrote: TblVendor Although, as I've posted in the past, I completely disagree with using any kind of object prefixing such as tbl other than in VBA variables. Tony's Object Naming Conventions http://www.granite.ab.ca/access/tony...onventions.htm Tony's Table and Field Naming Conventions http://www.granite.ab.ca/access/tablefieldnaming.htm Tony If Steve were to drop the TblVendor nonsense and just name the table Vendors, if would be a giant step in conveying the idea that he is truly a competent database professional. Appearance counts for a lot when you are trying to sell yourself. Even though a database with names like TblVendor could be designed correctly, the Tbl Vendor creates an unnecessary barrier for many people. Of course I realize that prefixes Tbl, tbl, tbl_ , etc. have their defenders. |
#12
|
|||
|
|||
Your Opinion on Design Question
Are you now going to jump in and object to every response with object
prefixes embedded? You made that same point today in another newsgroup when it lay slightly nearer the OP's issue. In this case, it's far removed from the issue.. Shall we who embrace the Reddick naming convention jump on each of your posts and make a big deal out of the fact that you *don't support the most widely adopted naming convention for Access, VB and VBA*? We would be equally justified. More so, I believe. The more widely adopted the naming convention, the greater its value. Note that has nothing to do with the purity of the form nor with abstract "truth". As you know, you're free to create and embrace any naming convention whatever, including none at all. Everyone else has that same right to suit their own preferences. But, the bottom line for these newsgroups is *best help for OP". I suggest that we all propose solutions or ideas to OP according to our habits or as we believe it will best serve OP. I believe that the Reddick convention, which is the one most widely published and adopted, best serves novice and intermediate Access developers. Advanced developers will keep on using/doing whatever got them to that point. Too bad that your eagerness to refer to your own practices on your site caused you to single out a post of Steve's. Others then piled on. I don't know if you've been aware but his behavior has improved a whole bunch over what it was in years past. He has been doing a lot more responsible posting without the constant hustle of the unwary. Yes, it seems he can't help himself at times. Even at those times, I'd simply warn OP and just ignore Steve. John ...Visio is on him anyway. HTH -- -Larry- -- "Tony Toews [MVP]" wrote in message ... "Steve" wrote: TblVendor Although, as I've posted in the past, I completely disagree with using any kind of object prefixing such as tbl other than in VBA variables. Tony's Object Naming Conventions http://www.granite.ab.ca/access/tony...onventions.htm Tony's Table and Field Naming Conventions http://www.granite.ab.ca/access/tablefieldnaming.htm Tony -- Tony Toews, Microsoft Access MVP Please respond only in the newsgroups so that others can read the entire thread of messages. Microsoft Access Links, Hints, Tips & Accounting Systems at http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ |
#13
|
|||
|
|||
Your Opinion on Design Question
"John... Visio MVP" wrote in message
... I know this may be a hard concept for you, but simply put, tables are collections of objects and queries have actions. So Vendors would be a table, Vendor a record in that table and NewVendors a query. Hi John. Are you saying that a select query based on a table named Vendors would be called "NewVendors"? What would you name an Append query based on the same table? Regards, Keith. www.keithwilby.co.uk |
#14
|
|||
|
|||
Your Opinion on Design Question
"Keith Wilby" wrote in message
... "John... Visio MVP" wrote in message ... I know this may be a hard concept for you, but simply put, tables are collections of objects and queries have actions. So Vendors would be a table, Vendor a record in that table and NewVendors a query. Hi John. Are you saying that a select query based on a table named Vendors would be called "NewVendors"? What would you name an Append query based on the same table? Regards, Keith. www.keithwilby.co.uk I was thinking in terms of a generic query, something to differentiate a query from a table. An Append Query for the same table could be AddVendors. Queries are either a subset of a table or joined tables. There is always some qualifier (New, Add) that indicates what part of the table you want. For appends I like the qualifier to be something that indicates what is happening (like Add). "New" for me would indicate selection. You want the Vendors who are New. So long as the names are suitable, the "tbl" prefix is not really necessary. I look at it as the formality of placing "Mr" in front of a name. If you want a more formal environment, then use the prefix, but in most cases you should be able to look at someone and determine if they are male of female. (Note, I did say "most" cases. There are exceptions.) John... Visio MVP |
#15
|
|||
|
|||
Your Opinion on Design Question
Michael Gramelspacher wrote in
: If Steve were to drop the TblVendor nonsense and just name the table Vendors, if would be a giant step in conveying the idea that he is truly a competent database professional. That's a completely unwarranted assumption, and, I think, says more about the baggage you're carrying into the discussion than it does about the merit of any particular answer to the question itself. In the Access development world, it is standard practice, and to me, an Access developer who *doesn't* use it is the one who looks unprofessional. There are very good reasons for it in Access that derive in part from the application development environment and the way it presents information (and combines multiple namespaces in certain contexts). Now, I don't mean to imply that Tony is unprofessional -- he's obviously not, but his naming conventions always struck me as a quirk particular to *him*. And I think he's the bees knees despite it. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#16
|
|||
|
|||
Your Opinion on Design Question
"John... Visio MVP" wrote in
: I know this may be a hard concept for you, but simply put, tables are collections of objects and queries have actions. So Vendors would be a table, Vendor a record in that table and NewVendors a query. I think table names should be singular, as the table models a particular entity, of which there are multiple instances (records) stored in it. Many people use the convention of tbl + EntityName + ID where the first pair give you the table name, and the last pair the PK name of the table. Thus, the PK name of tblPerson would be PersonID. If you use a plural table name, you get tblPeople and PeopleID, the last of which would be referring to a single person. Of course, all of this depends on what conventions you use. If you don't name your PK fields that way, it won't justify the singular table name. But if you *do* use that convention (as many, many Access developers do), it is rather illogical to use the plural in the PK name. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#17
|
|||
|
|||
Your Opinion on Design Question
"John... Visio MVP" wrote in
: So long as the names are suitable, the "tbl" prefix is not really necessary. I look at it as the formality of placing "Mr" in front of a name. If you want a more formal environment, then use the prefix, but in most cases you should be able to look at someone and determine if they are male of female. (Note, I did say "most" cases. There are exceptions.) Seems to me that your suggestion of Vendors and NewVendors makes no sense, as it sorts the two far apart with no real benefit. Do you really need to have all your queries for new records (or whatever you're defining "New" to mean in your app) sorted together? Wouldn't it be easier to have Vendors and VendorsNew, so objects based on the same table(s) sort together? My linked tables have several prefixes, such as tbl, tmp and vbl (for SQL Server views), among others. I seldom use anything but qry for queries, though. I don't find the loss of sorting base tables together to be problematic. I remember the days before I adopted prefixes and how complicated my names became for queries in particular. I still have some of the same problem, but don't worry about it nearly as much! Once you have more than a couple of queries with the same base table(s), you run into that problem regardless of whether or not you use a prefix, and that's a much harder issue to solve. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
#18
|
|||
|
|||
Your Opinion on Design Question
"David W. Fenton" wrote in message
36.98... "John... Visio MVP" wrote in : I know this may be a hard concept for you, but simply put, tables are collections of objects and queries have actions. So Vendors would be a table, Vendor a record in that table and NewVendors a query. I think table names should be singular, as the table models a particular entity, of which there are multiple instances (records) stored in it. Many people use the convention of tbl + EntityName + ID where the first pair give you the table name, and the last pair the PK name of the table. Thus, the PK name of tblPerson would be PersonID. If you use a plural table name, you get tblPeople and PeopleID, the last of which would be referring to a single person. Of course, all of this depends on what conventions you use. If you don't name your PK fields that way, it won't justify the singular table name. But if you *do* use that convention (as many, many Access developers do), it is rather illogical to use the plural in the PK name. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ I guess we agree to disagree. I always consider tables to be collections of items and so use a plural name for a table. To access the table, the PK points to a record (a single item), so I would use the singular for the PK. So a table called People would have a PK of PersonId. I tend towards to the proper English terms rather than Entity names. Find Customer in Customers rather than Find pkCustomerId in tblCustomer My excuse was that I started this game long before naming conventions were even considered. Somewhere around here I have the chisel and stone tablet I used for programming. John... Visio MVP |
#19
|
|||
|
|||
Your Opinion on Design Question
"David W. Fenton" wrote in message
36.98... Now, I don't mean to imply that Tony is unprofessional -- he's obviously not, but his naming conventions always struck me as a quirk particular to *him*. And I think he's the bees knees despite it. You've summed it up for me there, I always use prefixes in names and nothing's going to change that because it helps me enormously in code, but the fact that Tony does otherwise doesn't diminish my respect for him. Keith. |
#20
|
|||
|
|||
Your Opinion on Design Question
On 25 Nov 2008 00:46:00 GMT, "David W. Fenton" wrote:
Michael Gramelspacher wrote in : If Steve were to drop the TblVendor nonsense and just name the table Vendors, if would be a giant step in conveying the idea that he is truly a competent database professional. That's a completely unwarranted assumption, and, I think, says more about the baggage you're carrying into the discussion than it does about the merit of any particular answer to the question itself. In the Access development world, it is standard practice, and to me, an Access developer who *doesn't* use it is the one who looks unprofessional. There are very good reasons for it in Access that derive in part from the application development environment and the way it presents information (and combines multiple namespaces in certain contexts). Now, I don't mean to imply that Tony is unprofessional -- he's obviously not, but his naming conventions always struck me as a quirk particular to *him*. And I think he's the bees knees despite it. Yes, you are probably correct about the baggage. Been reading too much of Celko, too much time perusing the sqlserver.programming newsgroup, too much pondering the Microsoft templates for Access 2003. Ten years of casual use of Access and following the Access newsgroups and reading Access books, and ten years of seeing the tbl- prefix propagated upon wave after wave of new Access users. Sure, I know the reason. Because it is just the right thing to use for Access tables. How else can a person know whether Vendors is a table or a query? It is just a matter of style. We can leave it at that. |
Thread Tools | |
Display Modes | |
|
|