何时从电子表格切换到 RDBMS？
我曾自愿加入一个非政府组织，帮助他们在社区中心保存记录。目前，只有一个社区中心存储了他们的所有数据。然而，这种情况预计到今年年底将会改变。
目前，他们的数据是使用包含两张表的工作簿来维护的。主表中的每条记录在后续表中最多可以有 100 个后续记录。数据结构松散，没有明确的约束。
将所有现有数据从电子表格转移到 RDBMS 需要付出努力，但我愿意这样做；特别是因为有人讨论要与该领域的其他非政府组织共享上述数据。
一种替代方法是使用 Google Docs 等工具，并手动合并每组记录。
由于有多个数据输入和检索点，建议从电子表格数据库转向 RDBMS 是否有意义？
编辑 刚刚发布了关于遵循策略的后续内容 这里
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，迁移到 RDBMS 确实有意义，它是为了处理表结构的数据而设计的。
当电子表格相互引用时，事情往往会变得混乱，而且它们会不断增长，而关系数据库管理系统（RDBMS）可以很好地处理这一点。您可以通过 SQL 添加复杂公式等功能，其方式比使用电子表格简单得多。
这一举动（估计，对数据了解不够）似乎很容易，因为它已经组织得很好，并且您在问题成为问题之前就已经处理了它。
脚注：出于可用性考虑，我将允许用户继续使用与现在类似的 GUI 解决方案。您可以通过 csv 或其他文件格式导出/导入数据，例如 Google Docs 或 MS Excel，这仍然允许您在 RDBMS 中拥有后端以实现可维护性、速度和索引等。
http 上有一篇不错的文章： //www.cazh1.com/blogger/thoughts/2007/03/excel-vs.shtml 强调了使用的区别：
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: