>>>there are 2 patterns often used: just "ID" for the PK of every table or "ID_Tablename".
>>>Variations include PK_Tablename for primary and FK_Tablename for foreign keys.
>>>I personally prefer constant "ID_Tablename" as I always use the SQL alias in joins.
>>>
>>Thank you very much for your input.
>
>on rereading: I have not put enough emphasis on thinking through the options, deciding
>but then staying consistent throughout. Not only this cuts down on your code
>and mental effort - if you ever have to open part of the data via web tools/fwks
>like RoR, Django, Web2Py (and probably some others as well)
>you can set such a pattern as basic pattern in all modern fwks/ORMs for all tables by
>overwriting the strategy of the fwk at the app level -
>setting up your own "convention" instead of [individual table] configuration.
>
>If your app needs different key types (GUID for unattached client side evoked,
>IID for server side generated), think about using a generalized hungarian notation,
>even if this fell out of favour for variable naming due to static type info -
>in pure SQL the old argument still holds true ;-)
>
>regards
>
>thomas

I can't agree with you more on the emphasised point of staying consistent. The reality is that I am converting a VFP database application to a SQL Server or rather either or both back-ends. The naming conventions I have used in the VFP database/tables is very inconsistent. Over the years (25+) I have been changing my naming conventions based on this or that article of a guru or expert I would read. So I ended up having a mishmash. Now I need to have my SQL server names to match the VFP names in order for the application to work with either. I am constantly refactoring my application and names to make it more consistent.
Thank you.