I agree with Rox in a prior post!
I think that the Hungarian naming schema is great for your code but poor for data, IMHO. Having worked with multipe developers on a multi county state wide project we mandated that all fields have the prefix of the table they resided in. So CU_PK was known by all on the project as customer Primary key. IN_CU_FK shows the foregin key for the invoice master file pointing to the customer file.
Had the both been named iID it would have been confusing. In that system we had over 20 + tables that were all related so our naming structure was a saviour.
This issue is missed in all standards documents that I have seen on the net.
So seeing CU_ID, IN_ID, PA_ID are all very good ideas. When you have joined tables in a view you need to have the unique id for each table. Now they all don't the same.
__Stephen
>Stephen,
>
>As primary keys, iId is fine, you seldom need to have multiple primary keys in the same view. As foreign keys, iCustId and iInvId are OK and are unique for view fields.
>
>HTH
>
>Rex
>
>>I think that you are corect to unique your keys. IID, will look like IID_A, _B, _C in your joins, but iCustID vs iInvID will never be confused.
>>
>>If you use views keep them separate! If you don't use views, keep them separate!
>>
>>__Stephen
>>
>>
>>
>>>Hi everyone,
>>>
>>>We are new to the framework and have a question. We are now in the process of building our tables. Does the unique ID of the table have to be IID? I noticed most of the examples and things that we looked at in class referred to it as either IID or CID. Can we name it something else other than that? For example, we have a table called Product. Could we call it IProductID instead?
>>>
>>>Thanks,
>>>
>>>Brian
