views:

105

answers:

3

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, men of wisdom, what's your take on the roles of databases, config files, and spread sheets?

+2  A: 

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.

S.Lott
+1  A: 

For me, I want all of the core data to be stored in a database. Two reasons:

  • to allow adhoc reporting access to the data
  • to allow applications to share data.

Databases should contain all of the domain data, and occasionally some on-the-fly data (user preferences for example). Relational databases are most popular, but for some apps there are other options.

The config file on the other hand should contain all of the 'parameters' you want to change in the system; the ones that are not changed rapidly (on-the-fly). Config items are flexible, but not easily, and usually not from the interface. If it's a param that you only want the coder to possibly change, that should be right in the code (so no one else has access).

If you want to fiddle with data mining, provide some generic mechanism to download a CSV file with the results of a SQL query, directly into Excel. That way people can fiddle with pivot tables, without having to alter the application's schema.

Paul W Homer
+2  A: 

Spreadsheets are documents, databases are repositories for information, configuration files store rules for how a specific instance of an application should behave. If you think of it that way, it's usually not hard to make a call.

MNGwinn
What if you have a template application which is used primarily for replication, then customize to satisfy specific needs, where tabs and work flows can be added, removed, or reordered, where would you place the workflow definition?
Haoest
I'm not entirely sure what you're describing. If it's an application that's installed for a customer and then customized once for all users, it probably makes sense to put the definitions in a config file. If users are allowed to define and publish new workflows, a database probably makes sense.
MNGwinn