Good day,
Is ODK compatible with NoSQL databases?
Also, do you have any information regarding a control-panel to manage multiple ODK Aggregate main-user accounts (not device users)?
Kind regards,
Peter
If you are not interested in strongly-typed data, look at FormHub and ONA
(ODK Collect works with both of these servers).
NoSQL databases are generally document-based, which means it is easy to
constantly change your surveys, adding and removing questions, and changing
the answer-types of questions (e.g., from string to integer).
The problems come when you want to analyze that data.
If you are not disciplined, it can be a nightmare to unify and analyze
results from dozens of slightly-different surveys.
···
================The ODK server, ODK Aggregate, is built on top of a SQL data layer with
strongly-typed data columns.
If you add or remove questions, or change the question's answer type from
string to integer, ODK Aggregate forces you to change the form_id for the
collected data and store that data in a completely different data table.
This keeps each different version of your survey in a different data table,
and makes it an explicit step in your analysis to combine or merge these
different data tables (but if you are just changing the question text, or
adding a translation, you can do that without changing the form_id).
This forces you to make an explicit decision as to when you have enough
corrections and changes in a form to warrant moving all of your data
collectors to the newer form_id.
We feel that this makes it much easier to work with the collected data.
But it does mean that constructing the surveys is much harder -- you really
need to think about what you want to ask, and how you are going to analyze
the data, before you collect the data.
This is why we also strongly encourage teams to do a very small pilot
first, to refine and adjust the surveys.
On Thu, Apr 16, 2015 at 10:58 AM, toffiehosting@gmail.com wrote:
Good day,
Is ODK compatible with NoSQL databases?
Also, do you have any information regarding a control-panel to manage
multiple ODK Aggregate main-user accounts (not device users)?Kind regards,
Peter
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
FYI, we've just this week abandoned the Aggregate convention on this, with
our latest SurveyCTO release. We're still using MySQL, but we basically
just store XML on the server and we do sensible things with data exports
that include data from different versions.
It's very true that people can get themselves into trouble -- particularly
when changing data types -- but the human welfare cost during development,
piloting, and ultimate deployment (during which it's still incredibly
common to want to add questions or calculations from time to time) was just
far too great. And in our model where we strongly encourage use of
encryption, most data is ultimately unreadable on the server side anyway...
so we might as well just store it all as BLOBs.
Best,
Chris
···
On Thu, Apr 16, 2015 at 2:19 PM Mitch Sundt wrote:If you are not interested in strongly-typed data, look at FormHub and ONA
(ODK Collect works with both of these servers).NoSQL databases are generally document-based, which means it is easy to
constantly change your surveys, adding and removing questions, and changing
the answer-types of questions (e.g., from string to integer).The problems come when you want to analyze that data.
If you are not disciplined, it can be a nightmare to unify and analyze
results from dozens of slightly-different surveys.================
The ODK server, ODK Aggregate, is built on top of a SQL data layer with
strongly-typed data columns.If you add or remove questions, or change the question's answer type from
string to integer, ODK Aggregate forces you to change the form_id for the
collected data and store that data in a completely different data table.This keeps each different version of your survey in a different data
table, and makes it an explicit step in your analysis to combine or merge
these different data tables (but if you are just changing the question
text, or adding a translation, you can do that without changing the
form_id).This forces you to make an explicit decision as to when you have enough
corrections and changes in a form to warrant moving all of your data
collectors to the newer form_id.We feel that this makes it much easier to work with the collected data.
But it does mean that constructing the surveys is much harder -- you
really need to think about what you want to ask, and how you are going to
analyze the data, before you collect the data.This is why we also strongly encourage teams to do a very small pilot
first, to refine and adjust the surveys.On Thu, Apr 16, 2015 at 10:58 AM, toffiehosting@gmail.com wrote:
Good day,
Is ODK compatible with NoSQL databases?
Also, do you have any information regarding a control-panel to manage
multiple ODK Aggregate main-user accounts (not device users)?Kind regards,
Peter
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.