Naming conventions: Object ID
-
In our datebase we have a table called
Object
and it has a primary keyObjectID
. In our code we have an object calledObject
and 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: DB: Object.Id Code: Object.Id Now i use (last 4-5 yrs): DB: Object.ObjectId Code: Object.ObjectId I can't remember the reason for the switch, but there was one. Aside from whatever the reason was, i find Ta.TaId == Tb.TaId gives me a warm fuzzy. The lack of symmetry in Ta.Id == Tb.TaId bothers me. As far as DB vs Code, i don't see a compelling reason to change the name going from one to the other. It also makes script gen-ing one from the other a bit of a pain.
...cmk Save the whales - collect the whole set
-
In our datebase we have a table called
Object
and it has a primary keyObjectID
. In our code we have an object calledObject
and 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 generally do this application-wide. If something represents the exact same thing, then it has the exact same name. I have contact_id in my database and it's used as a primary key and foreign key, but as long as it represents the ID of a contact, that's what I call it, and I never use the name contact_id for anything else. If I add a special context to it, I keep the base, but add to the variable name (sender_contact_id, recipient_contact_id, etc.). I keep this convention in stored procs and application client code as well. Makes it kinda funny when you see: where contact_id = @contact_id ... but any SQL programmer worth a damn should understand that.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
In our datebase we have a table called
Object
and it has a primary keyObjectID
. In our code we have an object calledObject
and 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
As an example, this is what I do: class Customer
Customer.Id Customer.Name Customer.Address Customer.Stuff Customer.DifferentStuff
class OrderOrder.Id Order.CustomerId Order.Quantity Order.Stuff Order.DifferentStuff
So, as you can see,Id
is the primary key ofCustomer
andCustomerId
is the FK ofOrder
-
In our datebase we have a table called
Object
and it has a primary keyObjectID
. In our code we have an object calledObject
and 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
---- I try to be totally consistent:- ---- [table_name].[field_name] [class_name].[field_name] Product.Id Product.Name Order.Id Order.Product_Id * foreign key becomes [table_name].[foreign_table_name]_[field_name] [class_name].[foreign_class_name]_[field_name] * Notice how . becomes _ ---- * field names Id type is unique number By type is person ie Order.CreatedBy Date type is datetime ie Order.CreatedDate ----
-
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
I usually ask the psycho guy...what's his name...Freud.;P