Hi all,
What is the difference between these tables in ODK aggregate?
Examples
SURVEY_TEST_HEALTH_PROBLEMS
SURVEY_TEST_CORE
SURVEY_TEST_CORE2,SURVEY_TEST_CORE3
SURVEY_TEST_IMAGE_BLB
SURVEY_TEST_IMAGE_BN
SURVEY_TEST_IMAGE_REF
Please i will really appreciate your help.
Regards
See http://code.google.com/p/opendatakit/wiki/AggregateDatabaseStructure
Hi all,
What is the difference between these tables in ODK aggregate?
- Tables that end with _CORE
- Tables that end with _COREn NB: n = numbers.
- Tables that end with _BLB
- Tables that end with _BN
- Tables that end with _REF
Examples
SURVEY_TEST_HEALTH_PROBLEMS
SURVEY_TEST_CORE
SURVEY_TEST_CORE2,SURVEY_TEST_CORE3
SURVEY_TEST_IMAGE_BLB
SURVEY_TEST_IMAGE_BN
SURVEY_TEST_IMAGE_REF
Please i will really appreciate your help.
Regards
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
This is more appropriate for the opendatakit-developers@ list. Moving the
discussion over there.
Hi Mitch
Thanks for the reply,i had read this site before.http://code.google.com/p/
**opendatakit/wiki/**AggregateDatabaseStructurehttp://code.google.com/p/opendatakit/wiki/AggregateDatabaseStructureAm really confused with the tables,when querying from the Aggregate
database.So please which tables does contain data from the users,or should i use tables in the _FORM_DATA_MODEL.when querying ?????
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
I am not sure what you are asking when you say "contain data from the
users" since technically all the data comes from some user.
Are you talking about user permissions, like defining the user
accounts? Or are you talking about the submitted data for the form?
User-uploaded forms will have table names that start with an
alphabetic character. ODK Aggregate 1.0 table names are prefixed with
"opendatakit." so as not to collide with ODK Aggregate 0.9.x tables.
The top-level table for a user-uploaded xform will end with _CORE or
COREn, where 'n' is a number. The name of the top-level table is
roughly formID + "" + groupName + "_CORE". But that is all shrunk
down to be less than 64 characters, so if you have a long form id, it
will be compressed into a shorter string. The same compression is done
for column names. If you have an xform with nested non-repeat groups,
the full path of the group is preserved, but similarly compressed.
The user data tables begin with names that do not have leading underscores.
To understand the mapping between the form definition and the user data
tables and the columns in those tables, you need to look at the rows in the
_FORM_DATA_MODEL table.
That table describes the mapping:
ELEMENT_NAME -> (ELEMENT_TYPE, ORDINAL_NUMBER, PERSIST_AS_SCHEMA_NAME,
PERSIST_AS_TABLE_NAME, PERSIST_AS_COLUMN_NAME)
The PERSIST_AS_... fields identify the table and column that hold the
values for that ELEMENT_NAME. The ORDINAL_NUMBER identifies the sequence
of fields within its enclosing group or repeat. The ELEMENT_TYPE identifies
the data type of this element (REPEAT, GROUP, GEOPOINT, STRING, INTEGER,
DECIMAL, BINARY, ...).
Since elements can be groups or repeat groups, and the same name could
appear in two or more form definitions (or nested under different enclosing
groups or repeats), the nesting of the ELEMENT_NAME is indicated through
the PARENT_URI_FORM_DATA_MODEL field (referring back to the _URI field of
this table), and the form definition to which an element belongs is
identified by the URI_SUBMISSION_DATA_MODEL key.
The URI_SUBMISSION_DATA_MODEL value refers to that same field in the
_form_info_submission_association table, where the FORM_ID for this form is
identified.
If your form has multiple-choice selections (), each such form
element is stored in a separate table, with the value held in a VALUE
field. I.e., the space-separated values in the submission XML are split
into the list of chosen selections, and one row is inserted in this
separate table for each selection.
If your filled-in form has image, audio or media attachments, each such
form element is stored in a trio of tables, ending ..._BIN, ..._REF,
..._BLB. This allows the file name, type, and size to be defined in the
_BIN table, and the _REF and _BLB tables hold a description of the sequence
of chunks, and the chunks themselves (respectively), that make up that
file. This allows for arbitrary-size files to be stored (without these 3
tables, image files would be limited to 1MB on MySQL).
Mitch
This is more appropriate for the opendatakit-developers@ list. Moving the
discussion over there.
On Fri, Aug 10, 2012 at 12:02 PM, IMOBI_2 jackson@imobi.co.za wrote:
Hi Mitch
Thanks for the reply,i had read this site before.http://code.google.com/p/
**opendatakit/wiki/**AggregateDatabaseStructurehttp://code.google.com/p/opendatakit/wiki/AggregateDatabaseStructureAm really confused with the tables,when querying from the Aggregate
database.So please which tables does contain data from the users,or should i use tables in the _FORM_DATA_MODEL.when querying ?????
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com