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.
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.
No comments:
Post a Comment