January 21, 2015 at 7:30 am
Phil Parkin (1/21/2015)
RonKyle (1/21/2015)
I use ID. It's an abbreviation that otherwise doesn't form a word.'Id' is an abbreviation of a single word ...
As I pointed out earlier, that is not necessarily true.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
January 21, 2015 at 7:34 am
... and ID is not? What is it then?
'Id' is an abbreviation of a single word and is therefore valid, at least in standard written English.
When abbreviating 'Company', would you write Co or CO?
This shows the problems of language. I don't abbreviate the word company in a column name. But words like Nato, radar, and flak are all (or were) abbreviations (yes, the last a foreign one). As far as ID in standard written english, I don't think I use that much. When I was in the Army, I would have written Military ID and not Military Id. The second one looks funny, which isn't the final arbiter of grammer, but it means I'm not familiar with it.
January 21, 2015 at 7:38 am
Koen Verbeeck (1/21/2015)
Phil Parkin (1/21/2015)
RonKyle (1/21/2015)
I use ID. It's an abbreviation that otherwise doesn't form a word.'Id' is an abbreviation of a single word ...
As I pointed out earlier, that is not necessarily true.
Have you worked with systems where AccountID really means 'Account Identity Document'?
I guess such systems exist, though judging by the responses to this thread, it would completely befuddle most T-SQL devs.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
January 21, 2015 at 7:41 am
Phil Parkin (1/21/2015)
Koen Verbeeck (1/21/2015)
Phil Parkin (1/21/2015)
RonKyle (1/21/2015)
I use ID. It's an abbreviation that otherwise doesn't form a word.'Id' is an abbreviation of a single word ...
As I pointed out earlier, that is not necessarily true.
Have you worked with systems where AccountID really means 'Account Identity Document'?
I guess such systems exist, though judging by the responses to this thread, it would completely befuddle most T-SQL devs.
No, but Drivers ID might occur more commonly 😀
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
January 21, 2015 at 7:48 am
RonKyle (1/21/2015)
... and ID is not? What is it then?
'Id' is an abbreviation of a single word and is therefore valid, at least in standard written English.
When abbreviating 'Company', would you write Co or CO?
This shows the problems of language. I don't abbreviate the word company in a column name. But words like Nato, radar, and flak are all (or were) abbreviations (yes, the last a foreign one). As far as ID in standard written english, I don't think I use that much. When I was in the Army, I would have written Military ID and not Military Id. The second one looks funny, which isn't the final arbiter of grammer, but it means I'm not familiar with it.
Perhaps Military ID means 'Military Identity Document' rather than 'Military Identifier', in which case the usage is perfectly sound.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
January 21, 2015 at 7:54 am
Perhaps Military ID means 'Military Identity Document' rather than 'Military Identifier', in which case the usage is perfectly sound.
Yes, I guess that makes sense. In any case, as a previous poster said, whether it's EntityID or EntityId or Entity_Id, pick something and be consistent. Having worked with systems with and without naming conventions, the withouts are invariably more difficult.
January 21, 2015 at 8:09 am
Sean Lange (1/20/2015)
Eric M Russell (1/20/2015)
I've used product_id. I like typing code in all lowercase, both keywords and identifiers, which is ok so long as underscores are also used for clarity. Also, I don't have to maintain (or argue over) CamelCase consistency.But then you have to argue over using underscores in object names. That is one I don't care for because imho they are more difficult to type than standard capital letters. When the name is short like product_id it isn't too bad but when the names get longer the underscore makes it difficult to read.
Using ID or id? I would go with ID, but I tend to get swayed by the way other fields have been set up. Like using DT for DATE, I prefer using DATE now but at one time used DT.
Now I have to disagree with you here Sean, I find using underscores makes it a lot easier to read. I would find it easier to read Product_Level_System_ID than ProductLevelSystemId. I also like to use underscores because not everyone is good at capitalizing the first letter in each word, product_level_system_id is still easier than productlevelsystemid. But it could be because I'm an old COBOL programmer and was used to having dashes in the names of the fields, product-level-system-id. 🙂
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
January 21, 2015 at 9:15 am
Eric M Russell (1/21/2015)
However, I would take issue with ID by itself, on every table. Anytime I see that, I have low expectations for how the rest of the database is designed.
Agreed about a zillion times over. The best is ID in the Product table but in the Orders table it becomes Prod_FK or some other completely ridiculous name that doesn't make things clear. One of my biggest pet peeves in naming is when a data element changes names across tables. The second is ambiguous names. Using ID as the primary key ends up violating both of those pet peeves.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
January 21, 2015 at 9:18 am
below86 (1/21/2015)
Sean Lange (1/20/2015)
Eric M Russell (1/20/2015)
I've used product_id. I like typing code in all lowercase, both keywords and identifiers, which is ok so long as underscores are also used for clarity. Also, I don't have to maintain (or argue over) CamelCase consistency.But then you have to argue over using underscores in object names. That is one I don't care for because imho they are more difficult to type than standard capital letters. When the name is short like product_id it isn't too bad but when the names get longer the underscore makes it difficult to read.
Using ID or id? I would go with ID, but I tend to get swayed by the way other fields have been set up. Like using DT for DATE, I prefer using DATE now but at one time used DT.
Now I have to disagree with you here Sean, I find using underscores makes it a lot easier to read. I would find it easier to read Product_Level_System_ID than ProductLevelSystemId. I also like to use underscores because not everyone is good at capitalizing the first letter in each word, product_level_system_id is still easier than productlevelsystemid. But it could be because I'm an old COBOL programmer and was used to having dashes in the names of the fields, product-level-system-id. 🙂
I honestly don't have an issue with underscores although I prefer to not use them. If working on a system I always try to adhere to established naming conventions. I strongly dislike abbreviating words in column names. I would be one who much prefers Date to DT. It is only 2 keystrokes and removes a lot of clarity. The name (pun intended) of the game is consistency.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
January 21, 2015 at 9:40 am
Sean Lange (1/21/2015)
below86 (1/21/2015)
Sean Lange (1/20/2015)
Eric M Russell (1/20/2015)
I've used product_id. I like typing code in all lowercase, both keywords and identifiers, which is ok so long as underscores are also used for clarity. Also, I don't have to maintain (or argue over) CamelCase consistency.But then you have to argue over using underscores in object names. That is one I don't care for because imho they are more difficult to type than standard capital letters. When the name is short like product_id it isn't too bad but when the names get longer the underscore makes it difficult to read.
Using ID or id? I would go with ID, but I tend to get swayed by the way other fields have been set up. Like using DT for DATE, I prefer using DATE now but at one time used DT.
Now I have to disagree with you here Sean, I find using underscores makes it a lot easier to read. I would find it easier to read Product_Level_System_ID than ProductLevelSystemId. I also like to use underscores because not everyone is good at capitalizing the first letter in each word, product_level_system_id is still easier than productlevelsystemid. But it could be because I'm an old COBOL programmer and was used to having dashes in the names of the fields, product-level-system-id. 🙂
I honestly don't have an issue with underscores although I prefer to not use them. If working on a system I always try to adhere to established naming conventions. I strongly dislike abbreviating words in column names. I would be one who much prefers Date to DT. It is only 2 keystrokes and removes a lot of clarity. The name (pun intended) of the game is consistency.
Yes consistency would be nice, to bad it never seems to happen, at least here. There is one group here that thinks as I do, underscores in ever name more than one word, others prefer to cap each word. Most of our field, table, SSIS names all have underscores though, most stored procedures are done with the cap method. It makes for a fun debate topic.:-)
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
January 21, 2015 at 5:48 pm
I don't really care whether it's Id or ID or id, but use Id usually. Of course if I'm in a database where every column name is upper case I'll use _ID, and if I'm in one where everything is lower case I'll use _id.
Tom
January 22, 2015 at 11:26 am
I use ID unless it is followed by another word, e.g. memberIdHistory
Don Simpson
January 22, 2015 at 12:04 pm
ThisIsYourID
tH!$1sy0UriDOndRUgs
Any questions?
January 22, 2015 at 12:22 pm
I prefer to use EyeDee as in ProductEyeDee.
😉
January 22, 2015 at 12:26 pm
Sean Lange (1/20/2015)
Eric M Russell (1/20/2015)
I've used product_id. I like typing code in all lowercase, both keywords and identifiers, which is ok so long as underscores are also used for clarity. Also, I don't have to maintain (or argue over) CamelCase consistency.But then you have to argue over using underscores in object names. That is one I don't care for because imho they are more difficult to type than standard capital letters. When the name is short like product_id it isn't too bad but when the names get longer the underscore makes it difficult to read.
I like underscores. I find it easier to read. In the absence of underscores, I like to use pascal case.
As for ID or Id, I will use either one, mostly because of the pascal case. Otherwise it should be ID (abbreviation of identity or identification). Of course, if you are using it to represent something else that could change. Maybe you mean IDaho or Indestructible Data.
The real key is to have documentation as to what it represents.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 15 posts - 31 through 45 (of 103 total)
You must be logged in to reply to this topic. Login to reply