David,
I don't see the need for a numbering system but If you do decide to apply a numbering system, I suggest that you use several digits and the same number of digits for each set of digits. I assume that you would put the number at the beginning of the name, so as to control the sort order then if you simply begin at one you will get a weird sort order that would go like this 1, 10, 2, 20. Having extra digits solves that issue. Gaps in the numbering allow for subsequent insertion of new names that you need to be between two other name.
For example if you have 0001People and 0002Places then later decide that you would like Addresses to list between People and Places, you would have to renumber 0002Places to 0003Places. On the other hand if you have 0001People, 00010Places, you can then later create 0005Addresses.
Although you didn't ask, naming conventions also apply to other objects. My convention for naming forms relates subforms to the main form on which they are used. For example, I might have a form for staff, named frmInterview. This for includes several subforms – frmInterview_Issues, frmInterview_Actions, etc. The subform name prefix is the name of the main form. I use a similar approach for report name. Occasionally, I have a form or report that is used as sub on multiple parent forms/reports. In that case I use the prefix frmsb.
Gelnn
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com]
Sent: Monday, February 6, 2017 3:59 PM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Back-end Table Naming and Organization
David-
All the common tables should be in one back end - particularly if the users of the applications need to share the same data. Beyond that, you should create one additional back end for each of the three applications that contain the tables unique to that application. A naming convention is good - use tbl for main data tables, and tlkp for tables that contain lookup data. Create additional prefixes if you think you need them, but I find those two usually do the job.
John Viescas, Author
Effective SQL
SQL Queries for Mere Mortals
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
(Paris, France)
On Feb 6, 2017, at 9:51 PM, david.pratt@outlook.com [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:
My application is "growing" in the sense that I am finding more things that the complete database application should be able to accomplish for the user. Currently I have morphed into three "applications" which all have some common tables. I can see now that I should have started with a split database but that is hindsight which I need to now correct by figuring out how to update all the common tables and place into a back-end.
There are going to be quite a few tables by the time this is all finished. I need to organize them and name them in an efficient manner. I have created a DataTables folder to place them all into. I have created a "COMMON" subfolder, and a sub folder for each database application and am planning to place all the tables which are common to all the applications in the common folder. And then the tables which apply to only the one application in that applications folder. Is this the best approach to organizing the tables? Or is it best to place them all in a common folder and use a naming convention to organize them?
How do you name tables for best organization? I will have "set up" tables, "look up" tables and "transaction" tables. Do you use some convention for organizing table names? I am not referencing just the use of "tbl" as a prefix, rather some manner to group table names to make development more clear.
Does anyone use a numbering system to control the order of tables in the tables list? Or is that a bad idea?
Posted by: "Glenn Lloyd" <argeedblu@gmail.com>
Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (4) |
Tidak ada komentar:
Posting Komentar