Naming conventions: Object ID

[Vagif Abilov]

It gives me a good feeling to know that in far Australia people argue about exactly the same question we have been discussing in Norway today :) We decided to use "XxxxxID" on the fields that come from the database. In other words - "ID", not "Id". Just to have common style. Screw FxCop!

Вагиф Абилов MCP (Visual C++) Oslo, Norway If you're in a war, instead of throwing a hand grenade at the enemy, throw one of those small pumpkins. Maybe it'll make everyone think how stupid war is, and while they are thinking, you can throw a real grenade at them. Jack Handey.

[Stick]

IMHO I would never 'prepend' the name of the object to it like ObjectID or ObjectId as Object.ObjectId is redundant. If I'm asking for a member of that object, I already know I'm in the object. I also tend to always use 'm_' as then all the members are together in suggestion boxes, although I use Visual Assist X with which you can just toggle only members on. I really don't like using the 'm_', and may drop that convention as my experience increases. I would definately try to be consistent with all the objects so you can "know" what it will be named by convention.

[Dan Neely]

machined metal in yellow fluid.

-- Rules of thumb should not be taken for the whole hand.

[eddlsda]

I usually have an abstract ModelBase class that contains not only an ObjectId but a VersionId. The ObjectId is the persistent identity and the VersionId provides support in optimistic locking and support for maintaining history when needed. When these are mapped by a concrete domain model class, The ObjectId does map to a column called ObjectId which is the persistent identity of the class. If the class wants to provide a more natural alias like FooId for Foo class then defining a property that just returns the ObjectId works nicely. If an object also has a business key then that is represented and stored too. For example, it is sometimes the case that some business domains want a natural (human-readable) key to identify instances of a particular class like Product. The key for me is not to use that key as the system key as it couples different concerns and if the company decides to redo how they identify their products you’re not hosed at the database level. In terms of foreign keys, I find using the Name of the table followed by ObjectId most useful. For example, given Foo and Bar, a relationship from Bar to Foo would have FooObjectId in Bar table that is the foreign key to the ObjectId in Foo. This not only indicates that the relationship is a system key link but what type of object is related (what you need to know).

Don Eddleman Principal Enterprise Architect Healthways

[Paul Watson]

Our DBA uses ObjectID in the database and, since I am using an ORM, I refer to it as ObjectID. So yeah, I get code like Object.ObjectID which gets on my nerves. I prefer "id" in the table and then Object.id in the code.

regards, Paul Watson Ireland & South Africa

Shog9 wrote:

I don't see it happening, at least not until it becomes pointless.

[HellfireHD]

Marc Clifton wrote:

Agreed. ID is for the OK, and fooID is for FK's.

I agree with this. I have found it beneficial for migrating data between databases (for partitioning or archiving) since with a common name for the primary key I can then write generic scripts to perform the migration and only need to worry about dependencies. I'll often go one step farther and also ensure that any descriptive fields are consistently named within the application (in other words either object.Name or object.Title, not both) allowing every row to be presented generically, eg. for a search results page. (Yes, I'm aware that I can just override ToString() in every class, and I do, but having a consistent column name lets the code generator do that for me.)

[Frank Wong]

Chris: Keep in mind that objects need an ID so as to stay unique in their application domain; otherwise, the effort is a waste. Operations on objects are basically creation, destruction, and modification. It is much easier to handle when the object is renamed outside the domain while the objectId stays the same. In my business an electronic component is called by a part number, then it is called by a reference designator in a PCB board; but it is given an objectID in a CAD file. Microsoft assigns Universal ID to objects so as to be unique for the entire world. So you have to ask how ambitious you want to promote your universe! Best Regards, Frank XrxDeveloper

[Rocky Moore]

Personally, I find it easier to use the object name with the ID. Yes, it can look better from a single object standpoint to have ".Id", but when you throw in FKs you have to use two naming conventions instead of just one because all FKs will be nameId and the PK will just be Id. To me that just seems mixed. For me, it is looks more consistent to use: Member { MemberId ProfileId AddressId Name Age IsFat HowManyWives } than: Member { Id ProfileId AddressId Name Age IsFat HowManyWives } In this example, when you use the member ID in another table as a FK, to the member table is is Id but the other table it will be MemberId, just does not seem consistent. And for what, typing a few extra letters? BTW, have to admit, I had to look up "tautology" :-O Common, keep it simple :)

Rocky <>< Latest Code Blog Post: Free grid for WPF! Time limited - act now! Latest Tech Blog Post: Scratch: fun for all ages for free!

[cmk]

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

[Jasmine2501]

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.

[andy_fcm]

As an example, this is what I do: class Customer Customer.Id Customer.Name Customer.Address Customer.Stuff Customer.DifferentStuff class Order Order.Id Order.CustomerId Order.Quantity Order.Stuff Order.DifferentStuff So, as you can see, Id is the primary key of Customer and CustomerId is the FK of Order

[JohnGriffiths101]

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 ----

[Tim Schwallie]

I usually ask the psycho guy...what's his name...Freud.;P