I now have a master table with all our data in a consistent format,waiting to be imported into a database.
Based on Kristin’s post about,it looks like the next thing for me to start doing is learning about how to use SQLite.It will definitely be really nice to not have to deal with different versions of CSV data,and I’m excited to learn more about how to implement it.
The ability to look up later in the day records that we created earlier to associate bench values is a feature that seems particularly cool,in terms of having everything in one place at one time.
2 Responses
Kristin Muterspaw
SQLite is very similar to other DMS, and particularly PostgreSQL and MySQL in that it is also a relational database management system. It’s different in that it’s an embedded DMS in the application that is using it, and the end-user cannot see it. The syntax is very similar to just regular SQL. We won’t use SQLite on hopper or anything, we will still be using PostgreSQL. We’ll be using SQLite for the storage of the data on the android application. Then, we’ll either dump or export to CSV to the server.
Now that the data is cleaned up, you should import it into a database. We should discuss what and how many tables to have. Do we want to have a table for each different trip? To me, that sounds like the smartest option. If for some reason we need to have all of the tables together, we can do that with views or queries. Or we can have a master table, and also one for each individual trip. Does the data still have random data entries from testing, or empty lines? I think we might want to get rid of those. Or any data entry without a geocode doesn’t seem really important to me. What do you think?
Deeksha Srinath
I’m not sure what makes the most sense to do,in terms of tables.While I do think it would be useful to have one table per trip(or place? so an Iceland table across the years,and the same for Nicaragua? ) I think there’s utility in having it all be in one table too,since if we ever need to reference a subset, we can always use views.
The data doesn’t have random entries from testing/empty lines anymore. I also got rid of the entries without geocodes since we can’t really use them in any analyses.