I think most of us would agree with most of your points - provided we remember to treat them as
guidelines, not hard and fast rules. For example, I agree about primary keys being numeric, but I wouldn't necessarily condemn a database where the PKs are, say, character strings.
A couple of other points:
- Number of fields to be kept "reasonable". I would tend to be suspicious of a table that has 60, 80, 100 or more fields; it would suggest a need to normalise. But that's not necessarily the case. If there's a good reason for a high number of fields, then that's how it should be.
- "A table has to relate to any other table only by one field (Foreign Key to Primary Key)". If you mean that you can't have multiple fields making up a foreign key, then I'm not sure I see the reason for that.
- Naming conventions. Personally, I don't use a naming convention to distinguish different objects (fields, tables, triggers,etc). Maybe I should. But I do think it's important to follow certain conventions in the actual names themselves.
In particular, I try to choose table names that exactly describe the entity, always in the singular, and without abbreviating. So,
customer, not
cust, not
cust_table, not
customers. The reason is simply to reduce the effort of remembering the names. You never have to ask yourself if it is, say, the invoice or the invoice
s table; you always know.
The same with fields. So, in the invoice table, the FK pointing to the customer would be named
customer, not
cust_id, and certainly not
FK_cust.
(I do stress that these are my personal preferences, not rules that I wish to impose on the world. That said, it is not often that I am in a situation where I have sole responsibility for choosing the names of tables and fields.)
Regarding PKs, my personal rule is to make them auto-incrementing integers. And I always name all of them simply
ID. Again, this is just to make the names easier to remember. Since the PKs are probably the fields you will refer to most often in your code, this simple rule can save a lot of thinking and a lot of opportunity for error.
Apart from the above points, there's lot to like in your guidelines. Thanks for posting them.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads