naming conventions

- [Narrator] Another worthwhile topic that we should get into before we start actually laying out our data inside of Microsoft Access is naming conventions. Naming conventions are used most often by very serious database developers, and the de facto standard in the industry is called the Lezinsky-Reddick naming convention. If you look at the screen in front of us now, the naming conventions that I have listed here follow those two methods. The first on the left hand side is one that you've already seen.

You'll recognize these data objects, and I think that some of the important elements here is that each object begins with a capital letter and is followed by lowercase letters. Never put a space in an object name. These are all tables within our database, but every one of these tables has a single name. For example, SalesReceipts, there is no space between the words. Capitalize the first letter, capitalize the first letter of the next word, and that's the way it reads, but you should never ever use spaces.

It creates complexity when you're trying to use formulas or external database objects. The example on the right hand side closely follows the Lezinsky-Reddick method, and that is that each table is prefixed with the data type, so because these are tables, the lower case tbl, which is the short form for table, gets placed before. Personally I find that a little more difficult to look at. Of course I'm sure that after you look at it for long enough you get very accustomed to it.

I don't object so much to the table prefix because that makes perfect sense, but take a look at this. If I'm going to use a table prefix then I want to put an underscore so that again it becomes easy to read from an English standpoint. tbl_Customers, not a space, allows me to still view customers, inventory, employees, et cetera separately from the date type and still follow Lezinsky-Reddick method. Specifically, if you're going to use the underscore to separate your object from it's prefix query should have a qry, forms frm, subforms, which we'll talk about later, reports rpt, and macros.

These are just a handful of the data types that need to be accounted for, but I think that this is a good compromise between a strict naming convention method that creates confusion and one that adds clarity. I'm going to go back to the previous screen. The left hand column is what I'm going to use for my table names, and here I will use the query, form, subform, report, and macro prefixes for those data objects, so you'll easily at a glance be able to tell the difference from a form and a table.

If I was going to follow the Lezinsky-Reddick method to the letter I would use this. And I think you can understand why this just creates too much confusion. You have a lowercase three letter prefix, or four letter at the most, that defines the data object. So I know that ids is a particular type of data object, chr is a character type so I've got a text object there and that's great, but I can also find that information by simply clicking on the object, and in the meantime it's easier for me to look at the AccountType, LastName, FirstName without the prefix.

Again, I'm sure if you worked with it all the time, the prefixes would melt away and you'd have no problem reading this whatsoever. So depending on the level of proficiency you plan on developing, start mapping out your naming conventions now. And for a full description of the Lezinsky-Reddick method, you can visit any one of 100 websites that describe it, define it, and offer you a printable table so you can follow it. As for me as we're working through this database, we're going to use the prefixes you see on the right hand side here and our table names will be as you see on the left hand side here without prefixes.