Excel is not a database.

 The reasoning goes like this:

1. Excel can have lots of tables.
2. A database has lots of tables. 
3. Therefore Excel is a database.

When Excel is used as a database it is the root of all evil.

The problem is that it is easy to make a table in Excel. The problems get worse when...

• You add more "related" tables into an Excel spreadsheet. 
• Your table becomes very wide or very long or both.

You can imagine one Excel table having a part number of a component and a description, cost, weight etc of the component. Then on another table you could have a list of assemblies which show which components are used in each assembly. But if the component part number changes you have to make a search and replace operation hoping: 

• that you don't miss any (because
  of human error or formatting differences)
• you don't change any text which should not have been changed

I repeat, the problem is that it is easy to make a table in Excel. In other words you can make it without having to think hard about your objectives, about what the data is you are trying to represent.

I'll go into more advantages of a database over Excel in future posts, but here is the first:

If you make a table in (for example) Access you can force 

• the format 
• the uniqueness of rows. 

The idea to remember is force. In Excel it is hard to protect you data like that. In Access (for example) it is a built in.

Here is an example of a table:

 

Let's say that the first column of the table must always be 8 characters long and all the characters must be decimal digits as shown above. We can force things so that these rules are respected by clicking on the design view icon...

 ...and setting the first columns properties as shown below:

 

 So if you don't type in exactly 8 numerical digits you will get this sort of message:

 Actually if your codes are numerical there is another way to do the input checking, but I wanted to illustrate the general idea first.

I'll cover that in the next post...