It makes sense to use a convention when naming your fields, this can help in a number of ways, not least by allowing you to easily identify how a field should be used. Treat a field like you would a variable, give it a meaningful name.
What do I do? Well, I only have a couple of conventions I follow, these include…
1. Prefix a global field with g, eg gDate.
2. Prefix a summary field with a s, eg sInvoice Total. This is useful when building a 'system layout' in that it will easily allow you to identify the fields to leave off. Summary fields can have a big performance hit so should really only be displayed when needed.
3. Name the field with the same name you\d like to see as it's label when it appears on a layout. This is useful as it allows you to easily change all labels for a particular field in one hit if appropriate, such as a Customer Ref becomes Client Ref.
4. Keys. There are 2 type of key fields that I use when building a database, Primary and Foreign. A Primary Key is the unique identifier of a particular record and I generally call this PK_Unique ID, a Foreign Key is the value used to link a table to another table's Primary Key, I name these FK_Company ID. Note that if you use the same field name for all table Primary Keys it allows you to be cunning with dynamically naming fields in scripts and in CWP solutions.
No comments:
Post a Comment