Easy Naming Practices for .NET Coding

hexy wrote:

I would have to strongly disagree with your database naming conventions.

Tables:
Firstly, there isn't a real benefit with a prefix of 'tbl'. You know it's a table because it is an actual table object within the database. The biggest effect that this might have is having to take off the prefix with your eye to actually read what the tables 'real' name is e.g. TableName.

Are you going to have naming conflicts when not prefixing table names with 'tbl'? I would say probably not. At least not with a normalised database design. The only conflict I would anticipate would be with a table and a view, which might provide an extended look at the table info. Microsoft gets around this one in their CRM software like so:

Their database contains an AccountBase table and an Account view, which combines all the relevant info from the various tables that make up the 'account'. When they need to select an account in it's full form, they query the Account view.

Stored Procedures:
The same goes for stored procedures. MS prefixes there system stored procedures for a functional use, i.e. when a call to a stored procedure begins with sp_, it looks at global/system procedures first. It's not really useful otherwise. You know it's a stored procedure because it's a stored procedure object in the database. And again you'll limit the ease of use when looking at the list of procedures, in Enterprise Manager for example, because you have to remove the prefix as you read the real name.

Therefore I would think that the better convention is to name procedures like so:
TableName_Insert
TableName_Update
TableName_Delete
TableName_SelectAll or TableName_GetAll
TableName_SelectByKeyName or TableName_GetByKeyName

hexy wrote:

Key Names:
Microsoft has a default convention for naming Keys within SQL Server, and I'd recommend sticking to a similar convention.

Primary Key: PK_TableName
Index / Unique Key: IX_TableName or IX_TableName_ColumnNames
Foreign Key: FK_TableName_ForeignKeyTableName

hexy wrote:

Primary Key Name: tblNameIDPrimary Key Name:'ForeignKeytblName'ID

joycsc wrote:

First of all the all db object conventions, that i mentioned is from developer perspective. In database you don't really need to have 'tbl'/'spr' prefixes for database tables or stored procedures. But when developing multi-later applications, these prefixes become useful, as generally the code-generator utilities maps db objects to the corresponding logical-coding layer with the name in database server side. As you know there are lots of built-in and custom classes, we are using while coding. Having 'tbl' prefix in the db objects ( and thus in the corresponding logical layers and data containers ) increases the coding productivity by having the opprtunity to identify the db objects easily.

MyApp.BusinessLogic.Data.TableName.SelectAll<br />
MyApp.BusinessLogic.Data.TableName.SelectByKey<br />
MyApp.BusinessLogic.Data.TableName.Insert