Question

I have heard some genuine arguments for the use of relational database vs spreadsheet before. Relational database provides fast reporting and (relatively speaking) reliable data warehousing,where spreadsheets are lightweight, fast replicating, and easy to float around the organization to different audience. Although I notice the advantages of either, I can rarely distinguish what’s better in which scenario, and always end up using database.

In development, it’s easy to forget to consider other options when one can place config settings in the database. I’ve ran into quite a few apps where user menus, work flows and their orders, and constants are defined in the database level. While this is good if these entities were subject to change by end user from application level, it was not the case.

So, what’s your take on the roles of databases, config files, and spread sheets?

Answer 1

The old adage is this.

When you use a spreadsheet to solve a problem, you now have two problems.

Database is for records of the business. Long-lasting. Permanent.

Other configuration files are for other configuration information — not long-lasting business records. Current settings and what-not are not enduring business records, they’re part of a specific software configuration that processes the business records.

Spreadsheets are — well — they are what they are. Too complex to be a simple, configuration file. Too simple to be a real database.

Since they’re (almost) impossible to control, you need one standard, correct, idempotent result in the database. You should be able to rebuild spreadsheets from that controlled source.

Similarly, if you accept a spreadsheet for upload, you have to extract the data, and never refer back to the (almost uncontrollable) source document again.