If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Proper way to name objects..
Well said, Tom, I couldn't agree more. I always tell people that the most
powerful add-in to any DBMS is a good supply of pencils and paper coupled with the off switch on the computer. Get the logical model right and the rest falls into place, get it wrong and you end up jumping through hoops for ever more. Ken Sheridan Stafford, England "Tom Lake" wrote: A much more important thing is to design your tables properly! Names can be changed easily if they are't useful but a system built on bad table design can be very difficult to fix. Tom Lake |
#12
|
|||
|
|||
Proper way to name objects..
Thanks Ken. Well put. I'm stealing it for my own use... ;-)
-- Duane Hookom MS Access MVP -- "Ken Sheridan" wrote in message ... Well said, Tom, I couldn't agree more. I always tell people that the most powerful add-in to any DBMS is a good supply of pencils and paper coupled with the off switch on the computer. Get the logical model right and the rest falls into place, get it wrong and you end up jumping through hoops for ever more. Ken Sheridan Stafford, England "Tom Lake" wrote: A much more important thing is to design your tables properly! Names can be changed easily if they are't useful but a system built on bad table design can be very difficult to fix. Tom Lake |
#13
|
|||
|
|||
Proper way to name objects..
"Mell via AccessMonster.com" u18304@uwe wrote in news:5c5f2069e09b2
@uwe: Do these abbreviations have to be put in front of the name to be policitally correct as a good developer? Hungarian notation was firmly advocated by Microsoft engineers, at first in the apps department where it made sense, then in the systems department where it was corrupted beyond all usefulness, then in the user community where it make Access and VBA into a laughing stock amongst the resof of the professional world. Such is life. The worst offense is the appearance of these tags in things that are not programming objects at all, but user-visible GUI gadgets like tables and forms. You'll be pleased to know that with the advent of dotNet, Microsoft is taking the opportunity to disavow, repudiate, inadvocate and generally distance itself from anything even slightly like Hungarian. About time too. If this were the USSR, they'd be airbrushing it out of the photographs. If you are likely to be swapping code with MS, or with any major software house, then you may as well get used now to the camelCase and PascalCase conventions that are this month's de rigeur. If not, then it doesn't matter what you do as long as you (and your colleagues) can read it _reliably_ in nine months' time when you will have forgotten why you have a floating point number called "intTotal". All the best Tim F |
#14
|
|||
|
|||
Proper way to name objects..
Another way to help yourself and others as you develop a database, is to use
[Right-Click] [Properties] to add notes to your tables, queries, forms, etc. As you are designing a table, use the Description column to fully describe, without abbreviations, what a particular field is for. Documentation that exists inside the database cannot be misplaced. Even with a "proper" name, there can sometimes be questions later. "Mell via AccessMonster.com" wrote: I have been told that if you don't name your tables, queries, forms & reports like below than you did not build the db properly? Do these abbreviations have to be put in front of the name to be policitally correct as a good developer? 1. TABLES: tbl 2. QUERIES: qdf 3. FORMS: frm 4. REPORTS: rpt Any suggestions would be greatly appreicated. -- Message posted via http://www.accessmonster.com |
#15
|
|||
|
|||
Proper way to name objects..
Mell,
In Access you can now group into favourites queries/tables etc with related functionality (certainly in XP) - which helps with documentation without prefixes/suffixes (which is esentially the function of naming conventions). As has been said before in the dotNet world Hungarian notation is on the way out & camel/pascal case on the way in. The key is no 'funny' characters & spaces in names (in case you want to migrate to a different platform & Access sometimes corrupts queries with spaces & slashes in). I'd reiterate that if you want a polished product any convention you adopt should be invisible to your users. Regards, Chris. -- Chris Marlow MCSD.NET, Microsoft Office XP Master "Mell via AccessMonster.com" wrote: I have been told that if you don't name your tables, queries, forms & reports like below than you did not build the db properly? Do these abbreviations have to be put in front of the name to be policitally correct as a good developer? 1. TABLES: tbl 2. QUERIES: qdf 3. FORMS: frm 4. REPORTS: rpt Any suggestions would be greatly appreicated. -- Message posted via http://www.accessmonster.com |
#16
|
|||
|
|||
Proper way to name objects..
I agree with What Tom has said.
I have found that people are talking and moaning about the use of naming conventions when their databases are lacking the basic design principles. my reccomendation to anybody who i have talked to about naming conventions is if you want to use then is fine. I always stress however that a good database designer should ALWAYS create a developer's guide at the end of the project for the database which explains the use of each object in there along with other stuff. "Tom Lake" wrote: "Mell via AccessMonster.com" u18304@uwe wrote in message news:5c5f2069e09b2@uwe... I have been told that if you don't name your tables, queries, forms & reports like below than you did not build the db properly? Do these abbreviations have to be put in front of the name to be policitally correct as a good developer? 1. TABLES: tbl 2. QUERIES: qdf 3. FORMS: frm 4. REPORTS: rpt A much more important thing is to design your tables properly! Names can be changed easily if they are't useful but a system built on bad table design can be very difficult to fix. Tom Lake |
#17
|
|||
|
|||
Proper way to name objects..
Chris,
I agree. You are correct. Chris Marlow wrote: Mell, In Access you can now group into favourites queries/tables etc with related functionality (certainly in XP) - which helps with documentation without prefixes/suffixes (which is esentially the function of naming conventions). As has been said before in the dotNet world Hungarian notation is on the way out & camel/pascal case on the way in. The key is no 'funny' characters & spaces in names (in case you want to migrate to a different platform & Access sometimes corrupts queries with spaces & slashes in). I'd reiterate that if you want a polished product any convention you adopt should be invisible to your users. Regards, Chris. I have been told that if you don't name your tables, queries, forms & reports like below than you did not build the db properly? Do these abbreviations [quoted text clipped - 7 lines] Any suggestions would be greatly appreicated. -- Message posted via http://www.accessmonster.com |
#18
|
|||
|
|||
Proper way to name objects..
Thank you so much
mnature wrote: Another way to help yourself and others as you develop a database, is to use [Right-Click] [Properties] to add notes to your tables, queries, forms, etc. As you are designing a table, use the Description column to fully describe, without abbreviations, what a particular field is for. Documentation that exists inside the database cannot be misplaced. Even with a "proper" name, there can sometimes be questions later. I have been told that if you don't name your tables, queries, forms & reports like below than you did not build the db properly? Do these abbreviations [quoted text clipped - 7 lines] Any suggestions would be greatly appreicated. -- Message posted via http://www.accessmonster.com |
#19
|
|||
|
|||
Proper way to name objects..
Well put
Tim Ferguson wrote: Do these abbreviations have to be put in front of the name to be policitally correct as a good developer? Hungarian notation was firmly advocated by Microsoft engineers, at first in the apps department where it made sense, then in the systems department where it was corrupted beyond all usefulness, then in the user community where it make Access and VBA into a laughing stock amongst the resof of the professional world. Such is life. The worst offense is the appearance of these tags in things that are not programming objects at all, but user-visible GUI gadgets like tables and forms. You'll be pleased to know that with the advent of dotNet, Microsoft is taking the opportunity to disavow, repudiate, inadvocate and generally distance itself from anything even slightly like Hungarian. About time too. If this were the USSR, they'd be airbrushing it out of the photographs. If you are likely to be swapping code with MS, or with any major software house, then you may as well get used now to the camelCase and PascalCase conventions that are this month's de rigeur. If not, then it doesn't matter what you do as long as you (and your colleagues) can read it _reliably_ in nine months' time when you will have forgotten why you have a floating point number called "intTotal". All the best Tim F -- Message posted via http://www.accessmonster.com |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Date range on reports | Mark_Milly | Setting Up & Running Reports | 10 | January 19th, 2006 03:49 PM |
Show Database Objects | Carl | General Discussion | 9 | January 12th, 2006 03:18 PM |
Copied/Pasted objects move/reformat pre-existing objects | Great Scott 77 | Powerpoint | 1 | May 3rd, 2005 05:38 AM |
Using PROPER for Columns, rows or ENTIRE spreadsheet | Tom | Worksheet Functions | 3 | February 4th, 2005 03:43 PM |
accessing chart objects via VB | CycleMark | Charts and Charting | 1 | October 27th, 2003 04:52 PM |