All the comments you have received are right to the piont but if you read the 'feeling' of them you can see a trend. Namely there is no perfect way to do this. Each method has down sides. Adding table info avoids duplicates in your views (ie ID_a, ID_b ...) but uses character space. Views like fields of 10 characters or less. Adding type informaiton can be misleading (ie n = number & boolean) & uses character space. Not including the information causes duplicates to be created in your views.
Personally I have not included the extra information in my field names. I then have to rely on my Stonfield table printouts heavly to resolve duplicates with a lot of XXXXXX AS .... syntax. This is admitadly a pain.
I reserve naming conventions for variables as these can be as long as I feel like typing them.
One thing I am moving toward though is instead of using ID for key field names I am starting to use PK for primary keys and FK for foreign keys. Keeps my head straight and in many cases the end user has an 'ID' they want for customers & vendors (usualy from their existing accounting system). I used to get very confused by that so I switched names.
You can use what ever convention you wish as long as you are consistant. The only time you (as I do) will have a problem is when you are reading example code.
Good hunting
Terry
>I have been using the following convention for field naming in tables:
>
>TRANSACTION.DBF
>
>tr_id I(4)
>tr_code C(10)
>tr_dtime DATETIME
>tr_exported L(1)
>tr_cl_id I(4) (FK from client table)
>tr_pr_id I(4) (FK form products table)
>
>
>CLIENT.DBF
>cl_id I(4)
>cl_name C(30)
>cl_address1 C(30)
>
>etc.
>
>PRODUCTS.DBF
>pr_id I(10)
>pr_name C(30)
>etc.
>
>I have used FKeys as in the transaction table above so that one can easily know where the join is.
>
>Any comments on this naming scheme. I have been told that this is an OLD method and that the "NEW" thinking is to use :
>
>TRANSACTION
>id I(4)
>code c(10)
>productid I(4)
>clientid I(4)
>exported L(1)
>
>CLIENT
>id I(4)
>name C(30)
>
>
>PRODUCT
>id I(4)
>name C(30)
>etc.
>
>Comments and thoughts please.
>
>Bernard
It is impossible to make programs idiot proof. Idiots are too cleaver.
MCP( Tcp/Ip )