Arbitrary Naming Convention Question About Business Objects

Question

Ok, do you do Business.Name or Business.BusinessName SubCategory.ID or SubCategory.SubCategoryID

What about in your database?

Why?

I'm torn with both. Would love there to be a "right answer"

Answer 1

The only "right" answer is to be consistent. Decide upfront which one you will be using in a project, and stick to it.

Answer 2

For very common properties like "Name" and "ID", the convention I have used is to not put the entity name in the field. For more unusual properties, I do put the entity name.

This is a naming convention decision, but I have not regretted projects where this is the convention, if you put the name of the entity for each ID, it ends up seeming to be too verbose.

Answer 3

we do ID on anything that's the primary key. Saying SubCategory.SubCategoryID seems redundant,

Answer 4

The main drawback of using ID, Name etc is that you have to qualify them with the table name if you are writing an SQL join which overlaps two tables.

Despite that, I find it far more concise and readable to just use ID and Name - your code and tables will 'flow' much more easily past the eyes. Easier to type and less redundant. And typing SELECT Business.Name FROM ... in an SQL query is not really more troublesome than typing SELECT BusinessName FROM ...

In general, if I find myself repeating semantic information it alerts me to look for ways to eliminate it or at least recognise why it repeats. This could be on the small scale (attribute names) or the large scale (behaviour patterns or common class structures).

Answer 5

I may not be right, but I think Id is a tastier dish.

thing.id
because if you are going to write any reflective stuff that deals with your objects and needs primary key, its way easier to know it everywhere, then trying to determine it with a formula.

As for the other, thats total preference and I don't see any real implications other than time wasted typing the other characters, and its .net so no one actually types namespaces anyway.