There is programming, then there is programming correctly.

The wrong way to program is to do what the typical programming school tells you to do. The wrong way to program is to get an "MS Access for Dummies" book and follow what it says. That way of programming may be for if you want to make a program for your home use or for some very, very, very simple programs, but it really is extremely limited. How do I know this? I have been programming for about 18 years now, all in MS Access. I started out by learning from my older brother, who was a programmer at the time. He taught me the essentials. I then self-studied, not the beginner's books, but the more advanced books I got from the libraries and college book stores. I discovered a great deal about what it takes to make a real program.

Within the last 5 years I have been, off and on, taking on private students who were proessional programmers who needed help at their jobs. I also took on one who taught MS Access programming at various trade schools. I learned, quite quickly, that they had no skill at all that would enable them to survive in a professional office.

The teacher, mentioned above, (Let's call him "Mr. Z") was trying to create a database for a client of his and found he could not. Neither could any of the other teachers at the trade school where he taught. No one there had ever really created a database for professonal use.

The fact is, that I have seen so much incompetency in my field that I must assume that very few people can actually do what is required to create a professional database.

So what is needed? First and foremost, a person must thoroughly understand the most basic topic in programming: Data modeling.

What is Data? "Data" is a plural word. (The singular is "datum".) It means a collection of facts that you want to put into storage. A database is where you put that information.

A database can be any type of file system either physical or electronic. A filing cabinet might be a database if it is where you keep all of your records.

However, in computer programming, the database must be organized in a very special way. Before I tell you that way, let me tell you about the history of databases.

First, people would have it recorded on paper. A person who owned a store would sell his items and have to keep records of the sale. He would simply sell an over-the-counter item and ring up the sale on an old fasioned machine. He would, if he was smart, keep information about his stock (like quantities) and what the stock cost him to buy. A good businessman would know how much he sold and at what prices. He would keep this information in what was called a "ledger".

Most of the time the store owner didn't have to keep a record of whom his customers were. But when he started to give people credit (as in a credid card), which meant that they could buy things and owe him the money to be paid later), he had to enter the transaction into his ledger so that an accounting could be made.

This ledger was designed to carry the names of all his credit customers and how much they owed him. He would make entries when they bought something and another entry when he was paid. This was a simple database.

A smart buisness owner would have all of the transactions for a particular customer listen in the same part of his ledger so he wouldn't have to keep entering the name, address and other information repeatedly. Yet sometimes he might have to store other data having to do with that customer so he would, let's say, have to enter the person's name and address into another book if he were to create a mailing list for advertisement. He might have to do it again if he wanted to make a list of customers he wanted to invite to a year-end "thank you" party, or make someone elegible for discounts.

Now how would that change if the person's address changed? All those records would have to be manually changed also. That led to a lot of work and a lot of chaos because errors are made in repeated entries of the same information into several places. It was also time-consuming and expensive.

So, what was the solution? Keep the person's information in exactly one place and give him an account number. Now the account number referred to that customer in all of the places he kept information about that customer. A customer was uniquely identified by his unique idenetifier, now called a "primary key).

The same was now made true for each of the business' employees, creditors, potential customers on their marketing list and everywhere else that person's identity had to be stored and referred to.

This unique way of handling data is pretty new in businesses, (although the Social Security Administration issued a SSN, they used it for only one purpose to identify everyone in the system but that wasn't real data modeling). What made the "data model" was using an identifier for a person to be the same wherever you made a reference to that customer.

You would also have a unique identifier for your salesmen, your suppliers, your business associates and everyone, and everything else that was related to your business.

Therefore you could make a record that referred to a particular salesman who made a sale to a particular customer concerning a particular product or service - and all using just 3 unique identifiers to join the data together. You could then avoid having to write in names and other information long hand. You simply wrote the primary keys into one record. It was faster and easier.

This is data modeling: knowing how to assign primary keys to data and how the data is correctly related so that your business needs are correctly reflected in the database.

Now, sad to say, I have met very, very few people who have gone to school or taken courses in computer programming, who know enough about data modeling to make them professional. Yet I see them in positions as programmers making mistake after mistake and, like the Dilbert comic strip, have no idea what chaos they are creating. They usually make the database so that one particular customer can be reentered dozens or hundreds of times and they wouldn't catch it. Their data is hopelessly mangled. They can't even tell how many customers they have and which customers have multiple primary keys. These databases are totally unreliable.

Therefore, the first rule is to know how to model your data.

Then, how to maintain data integrity so that the computer can tell when you are about to accidently enter in a customer, or salesman, or somthing else, a second time. You get the picture? Data must be coherent, entered in only once and recallable.

After you have the data model correct you can build your interface around it.

What is an "interface"? It is the screens, the displays on your computer screeen, that enable your users to interact with the program in an easy and practical way.

Survey: I will not use this space for advertising. I just have to know if this site is sufficient or whether I should start offering lessons to those who want to advance. .
1: Please tell me if my writing style is coherent and understandable 2: Is the subject matter what you need 3: Do you want private lessons? (I charge $30/hr for lessons over the Internet one-on-one but group lessons can be formed with far, far less charge per person.) 4: If you want to know more information from this material as I post it on Soulcast, what information do you need? Are you a professional? A professional wannabe? A home-user?