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
-
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 says this is a tautology.
Yes, it is, in my opinion. I usually name my variables after their table's name, but in the case of the ID i just call them "ID".
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Personal Site
-
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
Object.PKey
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
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:
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 Smith -
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
-
Object.PKey
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!peterchen wrote:
Object.PKey
Hey Joe, what type is that peekey again? ;P 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 Smith -
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
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
-
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