>Hi Dustin.
>
>>I'm reading through "SQL Server 7.0" WROX book (highly recommended by many) and I noticed that their naming convention for field names do not use "c" or "i" or "n" (or anything else) before the field names to denote TYPE. (Example = nCustomerNumber, cName, tOrderDate)
>>
>>Usually in XBase examples, you see everyone doing this.
>>However, in SQL I see this less. Anyone have any thoughts on this? What are your normal procedures? Is it a 'waste' of time to do this in SQL or something?
>
>Actually, I think this is a waste of time in xBase too. It makes sense with variables because xBase is weakly typed (meaning you can put any value into any variable), so a naming convention tells the developer what data type is expected in a variable. However, fields in tables are strongly typed, so there's no need to use a naming convention to tell you the expected data type; just look at the table structure.
>
>My 2 cents (and I'm guessing I'll hear some opposing opinions <g>).
>
>Doug

I agree. I thought it was just me, but I never liked the format iCompanyID or cName in database field. My thought has always been that the only person who cares about this is a developer, and they should know the type of the field if they are doing any kind of work with it. If the user ever does see the field name, perhaps in a reporting application, I think Name looks better than cName.

FWIW:

1. I always use surrogate primary keys
2. My primary keys are integers, although I am considering GUIDs.
3. The name of my primary key is always table name + "ID" (i.e. CompanyID)
4. My foreign keys keep the name (i.e. in a child table of the company table, the foreign key remains CompanyID).
5. Rather than name a field CompanyName in the company table, I use Name.
6. If ever their is a duplicate field in a join (i.e. two fields, each named Name in the Company and Contacts table), I use the AS clause in the SELECT to change the field names.