 | |
#1
 
| |||
| |||
|
Naming question -
05-14-2010
, 02:47 PM
#2
| |||
| |||
|
|
I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars |
simple(r) since the two fieldnames match. Then again, I'd consider
whatever works and floats your boat. If you want, you can add a
description of the field in the table. You can always change the label
on a form and report if you ever display them.
#3
| |||
| |||
|
|
Lars Brownies wrote: I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars I probably would call it UserID. Linking the two tables would be simple(r) since the two fieldnames match. Then again, I'd consider whatever works and floats your boat. If you want, you can add a description of the field in the table. You can always change the label on a form and report if you ever display them. |
#4
| |||
| |||
|
|
I forgot to mention there's another field in that table which holds the ID value of the user who's handling this record (this is a request table). I can't call both UserID. So other options would be: EnteredByUserID, and HandlingByUserID I'm keen on getting this right, so I can make a rule of it. Otherwise I keep choosing different solutions every time, like I've done in the past. Lars "Salad" <sa... (AT) oilandvinegar (DOT) com> schreef in berichtnews:7-SdnUPi7KHYNnDWnZ2dnUVZ_oidnZ2d (AT) earthlink (DOT) com... Lars Brownies wrote: I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars I probably would call it UserID. *Linking the two tables would be simple(r) since the two fieldnames match. *Then again, I'd consider whatever works and floats your boat. *If you want, you can add a description of the field in the table. *You can always change the label on a form and report if you ever display them.- Hide quoted text - - Show quoted text - |
seems to work is the following:
UserID - Has the User ID and any information about user Ie name, date
start/end
In the tables/app reference with UserID_FUNCTION where the function is
the what the User ID does, ie entered, received, sold, shipped
UserID_Shipped
UserID_Received
UserID_Sold
UserID_Entered
Although the joins weren't automatic we always knew how to join things
then implicitly. You could even write code that would parse the joins
as well for automating things. With the description following the
original table name you know immediated that it is a USER ID field.
You'll probably have multiple dates as well and may call them
EnteredonDate etc...but this methodology is easy to follow and keeps
things clean. In my experience at least :P
Same thing for Dates actually
HTH,
Reeza
PS. Same thing for Dates actually...
Date_Recieved
Date_Entered...
#5
| |||
| |||
|
|
I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars |
#6
| |||
| |||
|
|
Larry Linson |
Lyle that was a member of this group as well.
#7
| |||
| |||
|
|
On May 14, 1:27 pm, "Lars Brownies" <L... (AT) Browniew (DOT) com> wrote: I forgot to mention there's another field in that table which holds the ID value of the user who's handling this record (this is a request table). I can't call both UserID. So other options would be: EnteredByUserID, and HandlingByUserID I'm keen on getting this right, so I can make a rule of it. Otherwise I keep choosing different solutions every time, like I've done in the past. Lars "Salad" <sa... (AT) oilandvinegar (DOT) com> schreef in berichtnews:7-SdnUPi7KHYNnDWnZ2dnUVZ_oidnZ2d (AT) earthlink (DOT) com... Lars Brownies wrote: I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars I probably would call it UserID. Linking the two tables would be simple(r) since the two fieldnames match. Then again, I'd consider whatever works and floats your boat. If you want, you can add a description of the field in the table. You can always change the label on a form and report if you ever display them.- Hide quoted text - - Show quoted text - One methodology I've used in business intelligence modelling that seems to work is the following: UserID - Has the User ID and any information about user Ie name, date start/end In the tables/app reference with UserID_FUNCTION where the function is the what the User ID does, ie entered, received, sold, shipped UserID_Shipped UserID_Received UserID_Sold UserID_Entered Although the joins weren't automatic we always knew how to join things then implicitly. You could even write code that would parse the joins as well for automating things. With the description following the original table name you know immediated that it is a USER ID field. You'll probably have multiple dates as well and may call them EnteredonDate etc...but this methodology is easy to follow and keeps things clean. In my experience at least :P Same thing for Dates actually HTH, Reeza PS. Same thing for Dates actually... Date_Recieved Date_Entered... |
#8
| |||
| |||
|
|
Naming Conventions, which are documented in detail at http://www.xoc.net/downloads/rvbanc.pdf. Not only do you save the stress, time, and effort of resolving questions such as you ask here, but if you |
Convention", which, at first look, looks quite similar. However, some
questions, like the one from this thread, aren't answered. I looked at the
link you provided, and maybe I've misread but I can't find the answer in
that document as well.
Lars
"Access Developer" <accdevel (AT) gmail (DOT) com> schreef in bericht
news:856a94FlilU1 (AT) mid (DOT) individual.net...
Quote:
|
Hi, Lars. I strongly recommend AGAINST inventing new personal naming conventions. A very, very large number of Access developers use the Reddick Naming Conventions, which are documented in detail at http://www.xoc.net/downloads/rvbanc.pdf. Not only do you save the stress, time, and effort of resolving questions such as you ask here, but if you come along after someone else, or they after you, the probability is higher that you'll have an easier time because you both use the same conventions. Some will say that it doesn't matter what convention you use, as long as you're consistent. That only applies if everyone who looks at your applications is in your company which has adopted an only-locally-standard naming convention. Larry Linson Microsoft Office Access MVP "Lars Brownies" <Lars (AT) Browniew (DOT) com> wrote in message news:hsk9co$319j$1 (AT) textnews (DOT) wanadoo.nl... I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars |
#9
| |||
| |||
|
|
Hi, Lars. I strongly recommend AGAINST inventing new personal naming conventions. A very, very large number of Access developers use the Reddick Naming Conventions, which are documented in detail at http://www.xoc.net/downloads/rvbanc.pdf. Not only do you save the stress, time, and effort of resolving questions such as you ask here, but if you come along after someone else, or they after you, the probability is higher that you'll have an easier time because you both use the same conventions. Some will say that it doesn't matter what convention you use, as long as you're consistent. That only applies if everyone who looks at your applications is in your company which has adopted an only-locally-standard naming convention. Larry Linson Microsoft Office Access MVP "Lars Brownies" <Lars (AT) Browniew (DOT) com> wrote in message news:hsk9co$319j$1 (AT) textnews (DOT) wanadoo.nl... I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars |
#10
| |||
| |||
|
|
On May 14, 1:27 pm, "Lars Brownies" <L... (AT) Browniew (DOT) com> wrote: I forgot to mention there's another field in that table which holds the ID value of the user who's handling this record (this is a request table). I can't call both UserID. So other options would be: EnteredByUserID, and HandlingByUserID I'm keen on getting this right, so I can make a rule of it. Otherwise I keep choosing different solutions every time, like I've done in the past. Lars "Salad" <sa... (AT) oilandvinegar (DOT) com> schreef in berichtnews:7-SdnUPi7KHYNnDWnZ2dnUVZ_oidnZ2d (AT) earthlink (DOT) com... Lars Brownies wrote: I'm still composing my personal naming convention and I have a question about it. In my apps I have a table tblUser with the first field: UserID. In a field in another table this ID number is used to store which user entered the data. I'm doubting what name I should give to this field. If I only call it UserID then the field name would not be descriptive enough. So I'm thinking about EnteredByID but I'm doubting whether I should add the ID part. I know there is no right answer to this question, but I do wonder what others would do. Thanks, Lars I probably would call it UserID. Linking the two tables would be simple(r) since the two fieldnames match. Then again, I'd consider whatever works and floats your boat. If you want, you can add a description of the field in the table. You can always change the label on a form and report if you ever display them.- Hide quoted text - - Show quoted text - One methodology I've used in business intelligence modelling that seems to work is the following: UserID - Has the User ID and any information about user Ie name, date start/end In the tables/app reference with UserID_FUNCTION where the function is the what the User ID does, ie entered, received, sold, shipped UserID_Shipped UserID_Received UserID_Sold UserID_Entered Although the joins weren't automatic we always knew how to join things then implicitly. You could even write code that would parse the joins as well for automating things. With the description following the original table name you know immediated that it is a USER ID field. You'll probably have multiple dates as well and may call them EnteredonDate etc...but this methodology is easy to follow and keeps things clean. In my experience at least :P Same thing for Dates actually HTH, Reeza PS. Same thing for Dates actually... Date_Recieved Date_Entered... |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.