Conversation started Sep 5, 2015 at 16:27.
user-------
user-------
Sep 5, 2015 16:27
Hi all, @Ixreq advised to ask here: meta.programmers.stackexchange.com/questions/7584/… . Is there anything to be improved before migrating this question to Programmers, or not? : stackoverflow.com/questions/32246376/…
user55340
-2
Q: Data storage without SQLite

user-------If you want to store data on Android that are too large for SharedPreferences, what would be an approach that avoids SQLite (and SQL altogether)? Object-relational impedance mismatch is a reason why it would be nice to avoid using the built-in SQLite database. The growing use of databases like ...

android orm nosql
user-------
user-------
@MichaelT Thank you.
user55340
(if you paste a link on a line by itself, in a message by itself, sometimes it will "one box" - if the site is whitelisted, like youtube, stack exchange, careers, area 51, wikipedia, amazon...)
user-------
user-------
@MichaelT I tried "a line by itself" in the same message, but the "line by itself" did not work :-(. New message is a good fix.
user55340
new message, and line by itself. Some people have tried one boxing multiple things at once. That doesn't work.
user-------
user-------
Sep 5, 2015 16:32
@MichaelT Yes, that's what you said in the last message. I did not get the "new message" from the FAQ, where it says "on a line by itself …"
user55340
To your question though, I'm sure you could use ORMlite. However, the problem you are trying to solve appears to be one that maps well into SQLite.
user55340
SnappyDB is a KVP database, and that means that you need to walk over all of the items to get the associated keys.
user55340
Sure, pulling one key by exact value out of a KVP is often faster than a relational database, but...
user55340
> The main read function is retrieving all log entries (after a certain date, maybe), and listing them to the user, allowing editing. Filtering by a certain Task.String, maybe in combination with a date limit, would be nice, too.
user55340
That's a perfect use case for a relational database.
user55340
Sep 5, 2015 16:37
select * from entry
where entry.date > ?
user55340
Sure, you can lay an ORM on top of it, but this isn't a situation where I'd see a document database or a kvp database to provide any advantages whatsoever over a classic relational database.
user-------
user-------
Sep 5, 2015 16:51
@MichaelT Thank you. While it would be a good fit, SQL seems such a kludge compared to key-value storage, though. It is just way harder to get working. Is that effort well-spent? (And Snappy can search for all keys with an item less than a fixed value, so the searching would be easy there, too)
user55340
@user------- Consider the problem "I want to get all of the entries from today", how do you do it with KVP?
Nick Alexeev
Nick Alexeev
@MichaelT I have read the Refactoring[F].
I'm looking for the concise way in which refactoring techniques should be documented. Like this, but for refactoring techniques. Not trying to write a book: Fowler & friends have done that for us, thankfully.
user-------
user-------
@MichaelT if you use the date as the key, you can use a snappyDB.findKeysBetween(
user55340
What about if you want to find all the ones that happen on Sunday?
user55340
What if you want to find all the days that a certain string occurred?
user-------
user-------
Sep 5, 2015 16:54
Yes, that would be possible with MongoDB (not on Android), but Snappy is a poor fit for that.
user55340
The core problem with a KVP database is that you only have one key.
user55340
Mongo has other issues... again, the "find between" requires that you look at all the values in that range. Sure, the KVP can do that quite quickly, but only for that one key.
user-------
user-------
db.keys.find({key: {$gt: 30, $lt: 50}}); in Mongo
user55340
You start doing things like getting "2015248" (thats YYYYDDD format) -> "id:42"
user55340
and then putting another KVP to id:42 to the actual data, so that you don't duplicate your objects.
user55340
Sep 5, 2015 16:57
But, behind the scenes, mongo now has to look at all those keys. It can do it quickly, but if you want to fetch on more than one field it becomes impractical.
user55340
You are describing a problem where a relational database is the perfect fit.
user-------
user-------
Thank you. Seems like key/value storage is a poor fit. Concerning Mongo: you can define an index for date, for example. (which, admittedly, is a bit more work, but possible).
Compared to SQL, Mongo is just so much easier. But maybe you are right, there, too. (You already were, concerning Snappy)
So the next step would be to either research document-based DBs or just to bite the bullet and use SQL. Thank you very much, again.
 
Conversation ended Sep 5, 2015 at 17:04.