Tuesday, 10 September 2013

Designing an app that sends updates to be parsed by a database

Designing an app that sends updates to be parsed by a database

I'm relatively new to this, but I promise I searched the forums and while
I found some similar questions, nothing really satisfied my needs. If I'm
thinking about this the wrong way then I'm open to suggestion.
I'm trying to design a very simple, lightweight mobile app that scans a
barcode (done), sets some flags including location and timestamp (also
done) and stores them in a simple table (I'm just using SQLite because
it's easy and comes with Android). These changes then need to be sent to a
database and parsed (any will do, I've got MySQL set up to try out). I
have a few very specific parameters though, which is why I couldn't find
anything that really fit:
I don't have constant or reliable connectivity. The changes can be batched
and uploaded, there's no need for real-time updating of the master tables.
I thought I'd just store the changes as a single table in the app and push
them to the server, or save as a file and upload via USB or something. The
live database may or may not even be connected to the outside world.
The app doesn't need a local copy of the entire database. I may add this
functionality later, but for now it just needs to be as light and simple
as possible, capture the data, store it, then give it to the server.
Essentially it's replacing a clipboard, pen, and hours and hours of manual
data entry in separate spreadsheets, which are getting way too big and
unwieldy.
Storing the history log would be a big bonus. In addition to current
status of the items I'm scanning I'd like to keep those transaction logs
generated by the app for building reports. I'm just worried that they're
going to get out of control huge really quickly, so it seems building the
server's tables around them is a bad idea. This is sort of the crux of my
confusion - what's the best way to keep the history but not let it get too
big, and also not build the database to rely on it, in case I want to
truncate and archive it?
Would it make sense to have the database parse the app's upload and then
create and store its own, separate, more economical history? The simpler
the better, I'm just doing this as a side project to save me tons and tons
of time manually entering data. The discussions and tutorials I've been
reading seem far more complex than necessary for my needs. I don't need to
develop commercial software, it only needs to beat the
pen/clipboard/spreadsheet model for now.

No comments:

Post a Comment