Access performance vs table field name
I would like to know if the number of characters of an access table field name can have an impact on performance.
Example:
If I use as field name, “client_name” instead of “name”, is it less efficiency
Thanks
Example:
If I use as field name, “client_name” instead of “name”, is it less efficiency
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Less is More ... I keep my field names as short as possible, and put a description (if necessary) in the Description property with more detail on the name
Seriously doubt there is any performance hit in Today's world of fast machines.
Dale ... why would a Reserved Word in brackets be less efficient ?
mx
Seriously doubt there is any performance hit in Today's world of fast machines.
Dale ... why would a Reserved Word in brackets be less efficient ?
mx
ASKER
Thanks everybody
Joe,
I meant to use NAME, without the bracket; with the bracket, I would not expect to see any significant difference.
Pat,
Generally, with DataSheets, I give each of the fields a caption to replace the column name in the datasheet headers. This allows me to use spaces, special characters and shorten the names where appropriate to make the datasheet more readable.
I meant to use NAME, without the bracket; with the bracket, I would not expect to see any significant difference.
Pat,
Generally, with DataSheets, I give each of the fields a caption to replace the column name in the datasheet headers. This allows me to use spaces, special characters and shorten the names where appropriate to make the datasheet more readable.
Thanks. Up until A2013 (possibly A2010), Access did very bad things with captions so I never used them and I only recently discovered that the issue has been fixed. I never display raw queries to my clients so it isn't a problem for them. And it isn't a problem for me because I avoid prefixes and a very long time ago, I adopted a standard set of abbreviations for my own use so I can keep my names as short as possible and not have to struggle with decisions to abbreviate/not abbreviate. Always abbreviate. Every application has a set of attributes and many of them are common words. Try not to abbreviate to the point that someone coming into the app can't read anything without a decoder ring in hand. But Customer is always Cust. Vendor is always Vend. Address is always Addr, Employee is always Emp, Account is always Acct, etc.
Pat,
Do you also use CamelCase for your field names? I use the same abbreviations, but frequently insert underscores to make the names more readable.
Do you also use CamelCase for your field names? I use the same abbreviations, but frequently insert underscores to make the names more readable.
I use CamelCase 99% of the time because it is more efficient for me to type. Having to shift and use the underscore throws me off. Of course all those years of COBOL where we used the dash as the separator didn't bother me and it's the same key. But, we used all upper case so there was no shifting at all. I guess it is the combination of leaving the letters rows AND having to shift. I only use the underscore if I want to highlight something. Of course typing CamelCase, you never shift or at least I don't. I feel sort of like ee cummings. Intellisense fixes up the case and if it doesn't, it is easy to see you have a typo. I wonder if Cummings would have used caps if he had intellisense?
Generally, I try to keep my field names to less than 20 characters, more for the amount of time it takes to type the darn thing. Never use spaces and avoid special characters.