Naming conventions: Object ID

[code frog 0]

A friend of mine (M.S. in Mathematics) paid for an entire year of grad school in two weeks. His job to put on this chemical suit and tear down an old chemistry solvent lab. He said it was horrible. The stench came through the suit at times. They had to stop every hour or so and drink a liter of water. (Texas in the summer.) Then suit back up and go back at it. He said the glue and solvents were the worst.:omg:

[code frog 0]

I think I just need to work less. Did you know I'm planning to take over the universe.:-D Rumor has it that you can do it with Linux.:rolleyes::doh:

[Gary R Wheeler]

code-frog wrote:

Rumor has it that you can do it with Linux

That's related to that whole world-domination-by-the-Teletubbies thing, isn't it?

---

Software Zen: delete this;

Fold With Us![^]

[code frog 0]

I think that's what happened to that one group in Waco who tried it with a Mac.:rolleyes:

[RoswellNX]

code-frog wrote:

He said it was horrible. The stench came through the suit at times. They had to stop every hour or so and drink a liter of water. (Texas in the summer.) Then suit back up and go back at it. He said the glue and solvents were the worst.:omg:

Well, i'd gladly take the job if it weren't just smells and hot weather. I'm actually pretty immune to chemical smells, but it's a different story with the effects the fumes themselves have on me. I've become almost allergic to a lot of solvents now, since i wasn't careful working with them at first. Like I can't tolerate nail polish because of the acetone. About the same with paint thinner... Roswell

"Angelinos -- excuse me. There will be civility today."
Antonio VillaRaigosa
City Mayor, Los Angeles, CA

[Howard Richards]

Since you asked.. my approach is usually KISS and try not to mangle stuff for the sake of mangling it unless there is a real benefit. I always name tables as plurals. "Customers" contains customers, not 'a single customer' - that's a single ROW of the table. So in your case my table is called "Objects", and PK is ObjectID as in your example. The data layer generates code for classes but converts the plurals to singulars, so the class is called "Object" but the field is still called "ObjectID", and there is a collection class which is called "ObjectCollection", which represents the table. I guess Object.ObjectID is a tautology but this is code we're writing, not English so it doesn't matter. It makes for a few more keystrokes but it keeps things clearer on what you're referring to.. This link http://vyaskn.tripod.com/object_naming.htm[^] was one I looked at when designing my current DB. I avoided using the underscore from their approach as this causes the CLR problems as it's not CLS compliant for names. I do however try to prefix all tables with a similar name to keep them together, e.g. Customers, CustomerServices, CustomerOrders etc.

'Howard

[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