Why wasn't I told that before?

We have been working with databases for over 30 years and with small business for over 20.

It is amazing how many times we have been called into a small business to help with their database requirements and having analysed the problem, hear the wail of "Why did nobody tell me that before?" 

The truthful but cruel answer is that either you didn't ask or were fed on bulldust. You can glean some comfort from the fact that somewhere like 90% of all other small business owners didn't ask either.

The biggest problem that small business owners have with data management systems is that they do not have a high priority in the early days, and rightly so. Then, when the business takes off, there are other more important things to think about.

Then comes the time when data capture and management can't be ignored.

"OK, I have to do it but it must be cheap." or "Just do it."

Both of these courses are building up trouble for the future. Doing it cheap may be an off-the-shelf package. A great deal of staff time and effort goes into adjusting systems to make the software suit, but it fails in the end. An additional problem then is that the data has to be transferred to a proper database application. That will cost a lot more than the original cheapskate package!

Then there is the database leach waiting for the too-busy manager. You will get what almost works, most of the time. What you won't get is what always works all of the time.

That makes sense. How much maintainance fees is he going to get out of you if he designs you a system that works all of the time?

So, what is your answer? Employ a firm that has the experience and the track record to help you. How will you know who is right? Talk to them (Or us.) You will quickly guage whether they can do the job or not. Go with your first instincts. Good developers are not good salesmen. In fact, we are very bad. If you feel any kind of flim-flam, talk to someone else. A person that is more interested in your data than your bank balance is a good indicator.

Technical details are not your area of expertise and should not be your concern. Flim-flam men will try to tie you up in knots about such stuff whilst pushing up the price. Ignore that. You know what you need. Tell them and ask for a fixed price. If you can't get that, move on. Then, you might want to talk to us?

Which database engine?

We have been working with databases for over 30 years and with small business for over 20.

During that time we have had many discussions with business owners and managers about which database engine they should use. Whilst those discussions have mostly been enjoyable, they have been a waste of time. The decision is quite easy to make:

Anyone reading this article is unlikely to be a database engine decision maker in a large business. We can therefore ignore SQLServer and Oracle. That leaves us with MySQL and Microsoft Access.

If you are a small business and want an on-line database, a web host who provides Access or SQLServer is going to be relatively expensive, with no obvious advantages. You can therefore safely decide on MySQL.

If you need a database that lives on one machine, there is no doubt that you need Access.

We are now faced with the decision of if we need multi-user access on a private network. Access and MySQL will both do this job exceptionally well. In addition, if you use the right developer, the cost of each will be the same, as will speed and ease of access.

Access is easy to install on a server but if the job isn't done properly, grief is the only result. The installation of MySQL requires more work which usually can't be undertaken by an amateur. In any case, the front end needs to be engineered by a professional database designer who is fully aware of your requirements.

Of course, the ultimate choice is yours but if you don't want to store up trouble for the future, discuss your requirements with your database developer.

Database development is not expensive. Mistakes are.

We have been working with databases for over 30 years and with small business for over 20.

Its very sad that we see so many small businesses over-sold with their database software. So often we find a small business that has started off with very basic data storage facilities. Somehow or other they have then acquired a Microsoft Access database and then gradually descended into database hell. Not because there is anything wrong with Access but because the "Developer" didn't really know what they were doing.

When it was first released, Access was seen by the database developer profession as a toy for amateurs. Sadly, many small businesses, unable or unwilling to pay for a professional, created or had created for them an Access database.

When first published, Access was unique and in some ways still is. For the first time, a database engine was combined with a GUI (Graphical User Interface) and development tools. Ordinary mortals could now create a proper database. As versions progressed, a unique and powerful programming language developed so that Access in the hands of a knowledgeable person became a powerful data management tool.
So far, so good. Now comes the sad bit.

Many Access developers were students on their way to somewhere bigger and better or people who thought they knew better than they did, then disappeared. Either way, we now have hundreds of thousands of small businesses trapped with an almost impossible-to-use database application and frantic to find a way out.

Que the sharks. Waiting in the wings are the database angels. So many times we have seen a small business sold a version of SQL Server or Oracle when all that was needed was a reconstruction of the data and a new Front End.

Database applications should always consist of two parts: The "Front end" is the application that the user interacts with. The "Back end" is the database engine that manipulates and manages the data itself. It is EXTREMELY IMPORTANT THAT THE USER DOES NOT HAVE DIRECT ACCESS TO THE DATA.. Not only is it inefficient, its dangerous.

Its crazy but the Access database engine (Known as Jet) is almost as good as you can get. The problem with Access out-of-the-box is that the GUI and the development tools are at the other end of the rainbow. That's why we don't use them. We use Visual Studio to develop your Front End. It's by far and away more efficient for you and is superb at producing the kind of reporting that you need for your business.

So why are we different? Firstly, we work for our client and we don't take commissions for selling packaged software. Secondly, we work for our client and try to give them the best possible database solution for their needs. Finally, we work for our client and keep the costs of employing us within the abilities of our client to pay. We are not in the business of ripping you off. We are in the business of helping business with their database needs.

Chocolate Teapots

Why would a person ever try to store hot tea in a chocolate teapot?

Well, the teapot would be easy to fill and would hold the tea for a while but it would ultimately fail. Why? Because it wasn't designed for the purpose.

This may seem like a stupid analogy but storing data in a spreadsheet is equally doomed to failure.

It's easy to store data in Excel. No programming knowledge is required and Excel is very user friendly. Copy and paste functions are available to try to keep data integrity. Filtering and sorting can be used and with expert knowledge, some form of report can be printed.

Sooner or later this becomes a fool's paradise. The spreadsheet soon becomes a massive file, difficult to manage and a nightmare to use.
The realisation then dawns that the data really ought to be kept in a proper database. Damascus here we come!

The problem is that it is no easy task to convert data held in a spreadsheet to a database, especially when we are dealing with large spreadsheets. Then what about database normalisation? How do we deal with duplicates? Which indexes should we use? Which is the best database engine to use? Should we publish on the internet, a private network or just have it on our own machine? How do we manage backups?

Some software engineers will help you with these problems, but most won't. That is because data migration is tedious, mind numbing work and clients are rarely willing to pay the true cost. We do it because we have many academic clients and more or less have to - but we don't like it.

The lesson for you is to use the right tool for the job at the start. Spreadsheets are for making calculations. Data should be stored in a database. Yes, spreadsheets can store data and databases can make some calculations but it is important to start out with the right package or grief will inevitable follow.