Naming question
in [Help]
|
From: Salad on 14 May 2010 23:37 Access Developer wrote: > Larry Linson I think I remember that name. It's been so long. There was a guy named Lyle that was a member of this group as well.
From: Salad on 14 May 2010 23:38 Reeza wrote: > On May 14, 1:27 pm, "Lars Brownies" <L...(a)Browniew.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...(a)oilandvinegar.com> schreef in berichtnews:7-SdnUPi7KHYNnDWnZ2dnUVZ_oidnZ2d(a)earthlink.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... Seems like an excellent suggestion
From: Lars Brownies on 15 May 2010 01:38 > 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 Thanks. In fact "my" naming convention is based on "Leszynski Naming 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(a)gmail.com> schreef in bericht news:856a94FlilU1(a)mid.individual.net... > 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(a)Browniew.com> wrote in message > news:hsk9co$319j$1(a)textnews.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 > >
From: Lars Brownies on 15 May 2010 01:47 One addition: I think a naming convention should mention reserved words and why not to use them. I don't see that mentioned in the RNC article. Lars "Access Developer" <accdevel(a)gmail.com> schreef in bericht news:856a94FlilU1(a)mid.individual.net... > 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(a)Browniew.com> wrote in message > news:hsk9co$319j$1(a)textnews.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 > >
From: Lars Brownies on 15 May 2010 02:00 Thanks. Good idea! Lars "Reeza" <fkhurshed(a)hotmail.com> schreef in bericht news:eeca5b28-f20a-47fb-9ce7-af2efb9e9efa(a)e21g2000vbl.googlegroups.com... > On May 14, 1:27 pm, "Lars Brownies" <L...(a)Browniew.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...(a)oilandvinegar.com> schreef in >> berichtnews:7-SdnUPi7KHYNnDWnZ2dnUVZ_oidnZ2d(a)earthlink.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...
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Software Developer - Princeton,NJ Next: I was hypnotised! |