• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Store 8000 elements of 500 bytes each -- what are some good solutions

 
Grey Smith
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to store and retrieve 8000 elements of 500 bytes each, for an Android application. I only need to look at 1 element at a time, and it's okay if it takes up to a second to load, though faster is of course nice. (The "elements" are data blocks, not full objects, because ObjectOutputStream involves a huge amount of overhead because of how my objects are structured (I could override it but that's a separate issue.) -- it'd take at least 3x this amount of space if I used it. )

I have no experience in storing data apart from reading/writing individual files.

I have a key assigned to each of the elements, and I've written code to put each of the elements in its own separate file (with a checksum). But I think this might be a naive solution and an unwieldy number of files (the files never have to be altered, however, so it's probably just a question of installation time?). I have no experience with databases and don't really want to get entangled with them unless I need to.

Is having 8000 files feasible, or will it take way too long to install on certain devices? If I store 10 elements per file and have 800 files, is that far preferable, or is it easier to do some kind of database approach?
What are some easy ways to do this? (If there's a good site to explain these issues feel free to link me -- I'm really not sure where to look for this information)

Thank you for any replies
 
Ulf Dittmer
Rancher
Posts: 42969
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

My first reaction is that you shouldn't worry about installation time - it only happens once per install after all.

There are two places files could go - "assets" and "res/raw"; not sure which one would be more performant. I haven't tried to use many files, but 8000 does not sound like a particularly large number to me. You might want to organize them into subdirectories, though, so "assets" might be a better place. Also because there is likely no need to refer to the files via an ID (as would be the case in "res/raw") - referring to them by file name should be sufficient.

My gut feeling is that importing the data into the DB would make retrieval speedier, but it's just that - a gut feeling. But since you already have code that reads and uses that data from files (if I understand your post correctly), porting that code to Android should be relatively simple - so you can just test whether access times would be acceptable.
 
Grey Smith
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, nice to be here.

Thanks for the rapid reply.

Great, that will save a bunch of time. Yes, I already have written and tested code for the files and arranged it to be easily portable for Android.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic