-1

I'm trying to figure out whether or not to use sqlite/spatialite on Android with only 29k rows. I just need to find the nearest locations from the user everytime they move outside 100 meters which could be about every 10 minutes. I feel like running querying a spatial database as opposed to looping a collection and calculating distances could be overkill. When is it overkill to use a database in this case?

Jisike
  • 383
  • 1
  • 3
  • 11
  • 1
    `... only 29k rows`. **ONLY**. Are you serious? – Phantômaxx Mar 25 '16 at 23:34
  • 1
    Best.Comment.Ever. – crazyPixel Mar 25 '16 at 23:40
  • only as in its not big data and as far as i can tell it doesnt take that long to calculate distances on 29k rows. and yes i seriously posted this asking for help... – Jisike Mar 25 '16 at 23:44
  • **29000** rows is not big data? You must be joking. Anything exceeding 10/12 rows (with a maximum of 2 columns, or else I'd say 5 rows or less) deserves to be stored in a database. A CSV file COULD be an option, but! Then it's no longer searchable. – Phantômaxx Mar 25 '16 at 23:52
  • i just need to find the nearest locations to the user. so its either i use a hashmap and calculate distances or use spatialite and query distances. – Jisike Mar 26 '16 at 00:03

1 Answers1

2

It's not overkill. It's actually probably required for you to store that data somewhere if you don't want your users to hate the app.

Running a constant process on your phone constantly consumes the phone's system resources. Consuming resources kills phone batteries. People don't like apps that kill their phone batteries. Repeatedly executing queries for that many records to a web service endpoint doesn't seem like the best idea either, since it would eat up your users' data plans. Users tend not to like that either.

29K records in active memory is probably more phone resources than you should be thinking about thinking about consuming unless you are doing something very, very special.

If your data doesn't change though, a database isn't the only way to store and query your data. There might a better solution somewhere in the middle, but I would not expect good results from consuming an unnecessary allotment of users' data plan and/or battery life.

smartcaveman
  • 41,281
  • 29
  • 127
  • 212
  • thanks for this helpful answer. i meant it'd be stored as a json or csv and loaded on run. but then i thought the amount of memory it would take to store it in a hashmap would be the same or less than a database. i currently have it running in database though. just wanted to see how i could cut down in resources and though maybe a hashmap would be lighter. – Jisike Mar 26 '16 at 00:52
  • You may find this helpful: http://stackoverflow.com/questions/7067798/how-to-decide-between-sqlite-database-vs-in-memory-usage – smartcaveman Mar 26 '16 at 00:54