When to switch from Spreadsheet to RDBMS?

Question

I've volunteered with a Non-Governmental Organization to help with their record-keeping at their community centre. At present, there is only one community centre where all their data is stored. However, this is expected to change by the end of the year.

Presently their data is maintained using a workbook with two sheets. Each record in the main sheet may have upto 100 follow-ups in the follow-up sheet. Data is loosely structured, and there are no explicit constraints.

Moving all existing data from a spreadsheet to an RDBMS would require effort, but I'm willing to do that; particularly since there is talk of making said data shareable with other NGO in the field.

One alternative would be to use, say, Google Docs, and merge each set of records manually.

With more than one point of data entry, and retrieval, does it make sense to recommend moving away from a spread-sheet database to an RDBMS?

EDIT Just posted a follow-up on strategy to follow here

Answer 1

Yes it does make sense to move to an RDBMS, which is made for handling data structured in just that, tables.

Things tend to be messy when having spreadsheets referring to each other and they just keep on growing, something an RDBMS handles well. You could add features via SQL such as complex formulas in a much more simple way than with spreadsheets.

The move (estimating, don't know enough about the data) seems easy since it's already well organized and you are dealing with this problem before it even is a problem.

Footnote: out of usability concerns, I would allow the users to hang on to a similiar solution as they have now, GUI-wise. You can export/import data to, for example Google Docs or MS Excel, via csv or other file formats, which still allows you to have the backend in an RDBMS for maintainability, speed and indexing etc.

There is a nice article on http://www.cazh1.com/blogger/thoughts/2007/03/excel-vs.shtml which emphasizes just that differentiation of use:

• quick & dirty: go for spreadsheets
• maintainability & long-term-storage: go for a database