Naming conventions: Object ID
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Part of me wants to stay consistent and have the object in code have an ID field Object.ObjectId, while part of me says this is a tautology.
Yeah. I call the meaningless numbers i use for primary keys "id". In code, and in DB schema. Only as foreign keys do they get a type/tablename prefix.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Chris Maunder wrote:
In our datebase we have a table called Object and it has a primary key ObjectID.
Unless there's a really good reason, I wouldn't have a table with such a generic name. But besides that, the PK would be "ID".
Chris Maunder wrote:
In our code we have an object called Object and it has an ID field called Id.
That's what I would do, but again, I wouldn't call the class Object. I guess you're not planning on having a class of that name in C#, are you?
Chris Maunder wrote:
Part of me wants to stay consistent and have the object in code have an ID field Object.ObjectId, while part of me says this is a tautology.
Agreed. ID is for the OK, and fooID is for FK's. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithWell, clearly I'm not actually calling the table and object "Object" :D. Close your eyes and pretend that I wrote "
CarefullyAndCleverlyNamedObject" everywhere you read "Object" ;) We stick to Object.ObjectID for the following reason: Object hasObject.ObjectIDObject.StuffObject.AnotherObjectID(FK) AnotherObject hasAnotherObject.AnotherObjectIDAnotherObject.DifferentStuffFK naming is then all nice and neat and obvious.cheers, Chris Maunder
CodeProject.com : C++ MVP
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
In every table that has a generic auto-increment PK I call the field the same name. I always use ThisTableSucksTheDBAIsOnGlueAndNeedsADrugTest as my primary key.
- I guarantee it's unique.
- It's certainly meaningful.
- It's always right. (Even if I'm the DBA.)
- It's very easy to remember.
- Nobody ever asks what it is or what it means. They know it's the primary key and it's never up for debate.
- What I say is final.
- There are no warranties at all express, applied, explicit, implicit or profane.
- My naming convention is inviolate handed down from my fathers, father a Jedi Knight for a 1000 generations who was always known as Darth Constraint.
Questions? Comments? Good!:laugh: For the record: This is post 4,918 :cool:
-
It depends. Are there a lot of different Ids on the class, or is it simple ? If it has a ton of different things on it, I'd tend towards naming it so it's clear which Id it is ( even though it's implicit ). If it's a struct with three properties, I'd just go with 'Id'.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
You ever tried selling the "we'll use this convention here, and a different convention over there" to Dmitry*? :D * Dmitry is one of the devs working the The Rewrite. He accepts no compromise. He scares us.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
Speaking from an "in the trenches" point of view having never taken a course or read a book on the subject, I name the database and code *exactly* the same, it saves a lot of hasssle. However I always prepend my database tables and column names with a single letter to avoid any possible conflicts with reserved words and make it easier to search and search and replace in my code by distinguising the two. However avoid using the letter "a" because two lowercase a's in a row is actually combined to a different letter in some northern European locales. (that was a frigging hard one to debug when it came across my desk). Oh yeah and I *always* name ID fields as ID, there is no need for the extra text, you're always going to see it prepended by it's table name in any db manipulation app I've ever seen anyway so your just adding confusion and extra typing for no reason.
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
Seems something.Id is right. FWIW, FxCop says something.ID (note the all caps) is wrong.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Check out this cutie The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Seems something.Id is right. FWIW, FxCop says something.ID (note the all caps) is wrong.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Check out this cutie The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
FxCop says something.ID (note the all caps) is wrong.
Yep, so I use .ID in SQL where FxCop can't give me a hard time, and Id in code. ;)
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Speaking from an "in the trenches" point of view having never taken a course or read a book on the subject, I name the database and code *exactly* the same, it saves a lot of hasssle. However I always prepend my database tables and column names with a single letter to avoid any possible conflicts with reserved words and make it easier to search and search and replace in my code by distinguising the two. However avoid using the letter "a" because two lowercase a's in a row is actually combined to a different letter in some northern European locales. (that was a frigging hard one to debug when it came across my desk). Oh yeah and I *always* name ID fields as ID, there is no need for the extra text, you're always going to see it prepended by it's table name in any db manipulation app I've ever seen anyway so your just adding confusion and extra typing for no reason.
John Cardinal wrote:
I name the database and code *exactly* the same
That makes sense technically, but from a readability point of view it's difficult because code allows namespaces, table naming doesn't. So we name our tables
ModuleObjectand the codenamespace Module
{
class Object
{
...cheers, Chris Maunder
CodeProject.com : C++ MVP
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
-
John Cardinal wrote:
I name the database and code *exactly* the same
That makes sense technically, but from a readability point of view it's difficult because code allows namespaces, table naming doesn't. So we name our tables
ModuleObjectand the codenamespace Module
{
class Object
{
...cheers, Chris Maunder
CodeProject.com : C++ MVP
Hey whatever works for you! :) I need to do a *lot* of dynamic sql in my code so I have a lot of mixed sql and code all over in my business objects layers and I've never found readability a problem but the main thing is to have some sort of standard and stick to it rather than the exact way it's done. Note also that I keep things short because I work in several different db layers and I'm up against a limitation of (IIRC) 30 something characters for FireBird so I'm always using lowest common denominator standards.
-
Well, clearly I'm not actually calling the table and object "Object" :D. Close your eyes and pretend that I wrote "
CarefullyAndCleverlyNamedObject" everywhere you read "Object" ;) We stick to Object.ObjectID for the following reason: Object hasObject.ObjectIDObject.StuffObject.AnotherObjectID(FK) AnotherObject hasAnotherObject.AnotherObjectIDAnotherObject.DifferentStuffFK naming is then all nice and neat and obvious.cheers, Chris Maunder
CodeProject.com : C++ MVP
Yeah the best way to solve naming convention issues is to ask the opinons of more developers. ;-) Having had to detangle some odd FK naming I like the consistant PK and FK naming approach. Consistant naming in layers is also very helpful. But consistancy is the key, so if someone is using ID for PK then I will use that. -- Leah
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
Welcome to War Database x OOP :laugh: I like of the second approach (Object.ObjectId and NOT Object.Id). If you use Object.ObjectId and to another fields you use the exact naming of table fields, do you will by example, use one List in a ASP.Net GridView directly, and update your database table without need worry about mapping of the field names, and a lot of another advantages what, if you wish I can list to you. :rolleyes:
:sigh: Still searching for a good resource to LEARN English grammar ... :~
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger: -
Yeah the best way to solve naming convention issues is to ask the opinons of more developers. ;-) Having had to detangle some odd FK naming I like the consistant PK and FK naming approach. Consistant naming in layers is also very helpful. But consistancy is the key, so if someone is using ID for PK then I will use that. -- Leah
Leah_Garrett wrote:
Yeah the best way to solve naming convention issues is to ask the opinons of more developers
lol.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
You ever tried selling the "we'll use this convention here, and a different convention over there" to Dmitry*? :D * Dmitry is one of the devs working the The Rewrite. He accepts no compromise. He scares us.
cheers, Chris Maunder
CodeProject.com : C++ MVP
No, I generally try more productive pursuits, such as walking on water and reversing gravity.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
In every table that has a generic auto-increment PK I call the field the same name. I always use ThisTableSucksTheDBAIsOnGlueAndNeedsADrugTest as my primary key.
- I guarantee it's unique.
- It's certainly meaningful.
- It's always right. (Even if I'm the DBA.)
- It's very easy to remember.
- Nobody ever asks what it is or what it means. They know it's the primary key and it's never up for debate.
- What I say is final.
- There are no warranties at all express, applied, explicit, implicit or profane.
- My naming convention is inviolate handed down from my fathers, father a Jedi Knight for a 1000 generations who was always known as Darth Constraint.
Questions? Comments? Good!:laugh: For the record: This is post 4,918 :cool:
code-frog wrote:
In every table that has a generic auto-increment PK I call the field the same name. I always use ThisTableSucksTheDBAIsOn_Glue_AndNeedsADrugTest as my primary key. * I guarantee it's unique. * It's certainly meaningful. * It's always right. (Even if I'm the DBA.) * It's very easy to remember. * Nobody ever asks what it is or what it means. They know it's the primary key and it's never up for debate. * What I say is final. * There are no warranties at all express, applied, explicit, implicit or profane. * My naming convention is inviolate handed down from my fathers, father a Jedi Knight for a 1000 generations who was always known as Darth Constraint. Questions? Comments? Good!:laugh: For the record: This is post 4,918 :cool:
:laugh::laugh::laugh: Glue? ouch! bad stuff... On a serious note, it's worse than any kind of muscle relaxant...i know the effects from making the mistake of working with several types the solvent-based chemicals indoors(all at different times). Most of that stuff affects the nervous system, sort of like a shock that comes in one wave and dislodges all emotions, as well as relaxing the muscles at the same time. The effect that causes the loss of muscle tone is actually pretty well documented. Other side effects are pretty product-specific, like some permanent markers (i remember they had the word "king" on the package as a part of the brand name, but i'm not sure if i remember it right) cause shortness of breath, and over a period of several days after the exposure lungs will respond and cause further breathing problems... Roswell
"Angelinos -- excuse me. There will be civility today."
Antonio VillaRaigosa
City Mayor, Los Angeles, CA -
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
I used to use ID however consistency won over and I now use Id. database field: customer_id database table: customer member: customerId; property: CustomerId; Another solution I use often is to provide an interface for objects from the db. In your case all objects would have the following interface: Int64? Id{get;set;} Of course this would not match the db. The reason the db needs the full prefix in the case of id columns is because of joins. You don't want to have to alias every join!
File Not Found
-
code-frog wrote:
In every table that has a generic auto-increment PK I call the field the same name. I always use ThisTableSucksTheDBAIsOn_Glue_AndNeedsADrugTest as my primary key. * I guarantee it's unique. * It's certainly meaningful. * It's always right. (Even if I'm the DBA.) * It's very easy to remember. * Nobody ever asks what it is or what it means. They know it's the primary key and it's never up for debate. * What I say is final. * There are no warranties at all express, applied, explicit, implicit or profane. * My naming convention is inviolate handed down from my fathers, father a Jedi Knight for a 1000 generations who was always known as Darth Constraint. Questions? Comments? Good!:laugh: For the record: This is post 4,918 :cool:
:laugh::laugh::laugh: Glue? ouch! bad stuff... On a serious note, it's worse than any kind of muscle relaxant...i know the effects from making the mistake of working with several types the solvent-based chemicals indoors(all at different times). Most of that stuff affects the nervous system, sort of like a shock that comes in one wave and dislodges all emotions, as well as relaxing the muscles at the same time. The effect that causes the loss of muscle tone is actually pretty well documented. Other side effects are pretty product-specific, like some permanent markers (i remember they had the word "king" on the package as a part of the brand name, but i'm not sure if i remember it right) cause shortness of breath, and over a period of several days after the exposure lungs will respond and cause further breathing problems... Roswell
"Angelinos -- excuse me. There will be civility today."
Antonio VillaRaigosa
City Mayor, Los Angeles, CARoswellNX wrote:
i remember they had the word "king" on the package as a part of the brand name
Eh, those stink. The ones that smell like banana mash are much nicer.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
In our datebase we have a table called
Objectand it has a primary keyObjectID. In our code we have an object calledObjectand it has an ID field calledId. Part of me wants to stay consistent and have the object in code have an ID fieldObject.ObjectId, while part of me says this is a tautology. What do you guys use?cheers, Chris Maunder
CodeProject.com : C++ MVP
I got to the point where I named a key StinkinKey, but now I tend to use KeyId.
-
In every table that has a generic auto-increment PK I call the field the same name. I always use ThisTableSucksTheDBAIsOnGlueAndNeedsADrugTest as my primary key.
- I guarantee it's unique.
- It's certainly meaningful.
- It's always right. (Even if I'm the DBA.)
- It's very easy to remember.
- Nobody ever asks what it is or what it means. They know it's the primary key and it's never up for debate.
- What I say is final.
- There are no warranties at all express, applied, explicit, implicit or profane.
- My naming convention is inviolate handed down from my fathers, father a Jedi Knight for a 1000 generations who was always known as Darth Constraint.
Questions? Comments? Good!:laugh: For the record: This is post 4,918 :cool:
-
Judah Himango wrote:
FxCop says something.ID (note the all caps) is wrong.
Yep, so I use .ID in SQL where FxCop can't give me a hard time, and Id in code. ;)
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Id in code
Blech. For some reason, I've always disliked '
Id' and 'id'; it's supposed to be 'ID', dammit. Sorry. I just finished doing my taxes X|. I'm feeling all middle-aged and irascible :mad:.
Software Zen:
delete this;