>>>>Walter,
>>>
>>>This is a bad rule.
>>
>>Why do you say that?
>
>Adding 3 letter prefixes to every column in a table looks meaningless to me and more to type. The column name should describe what this column represents, not have some extra garbage in front. Also, it's easy to use the same column name in the referenced and referencing tables, this way we can tell right away about relations between tables.
>
>Say, you would name column OrderId in Orders and OrderDetails tables. Wondering how would Walter name them.


You are too quick with your judgement I think. I've got several rules

in your example, if you are talking about a PK and FK relationship, the fields will postfix with PK and FK

Orders.Ord_Pk, OrderDefails.Odt_Ordfk

If you need an human readable identifier in Orders

Orders.Ord_ID

The idea behind it is that:
- Each name in the database is unique
- PK are identifiable
- FKs are identifiable and you know to what field and table it is pointing
- PKs and FKs are always integer

In VFP you will get several bonuses:
- No clash between fields and memory variables as I'm not using three letters + underscore prefixed variables
- Fields and variables are immediately distinguishable
- The origin of the field (Table) is immediately identifiable, even in the result of queries
- Since the uniqueness of fieldnames, it is easy to build metadata to store application (not necessary domain) wide or user preferred default values and validation rules for the field (Those do not belong in the database).
- And several others (e.g. building CA views on the fly)