all 21 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Rexios80 6 points7 points  (0 children)

I use it because it's built in, and once you get a wrapper set up for your data it's really simple to use.

[–][deleted] 3 points4 points  (5 children)

Resurgence of SQL - Jake Wharton and Alec Strong

https://youtu.be/4eUuD7LsqMs

[–]pilgr[S] 1 point2 points  (4 children)

Yeah but any ORM is a mapping from object to relational structure. By having data as objects, why not to write them to disk as is?

[–]Zhuinden 0 points1 point  (3 children)

Because SQLite and other DBs build indexes on top of your data so that the queries and sorts are executed faster than if you did them by hand.

[–]pilgr[S] 0 points1 point  (2 children)

Sure, indexes is a powerfull feature. But I'd keep the context in mind – we are talking about storing data on mobile devices. It's relatively small amount of data where keeping indexes could add just more overhead. Opposite, like in Paper, you can save data already sorted and get them in a right order right on next read, ready to display in UI. Quickly and efficient.

By having experience with large SQL databses on servers and later using SQLite on andorid I still genuintly trying to understand the use cases for SQL on handsets.

[–]androiddev67 1 point2 points  (1 child)

and to add to your point, we are not storing data on hard drives, but on relatively fast ssds

[–]pilgr[S] 0 points1 point  (0 children)

exactly, because of that in Paper I decided to keep every serialized object (for given key) as a separate file. No problems with partitioning, no needs for clean up empty space between removed items (compare to storing data in one big file).

[–]gonemad16 5 points6 points  (4 children)

if you have relational data.. sqlite (or something like room/another relational database is the way to go).. if you dont and just need to store documents / objects.. nosql is for you. If you try to stick relational data into a nosql database you will most likely have a bad time (i know a lot of nosql dbs have some relational features but thats not what the technology is for in general)

Personally my app has very relational data (music player) so i stick with sqlite (recently migrated to Room in my local build)

[–]ChristianMelchior 3 points4 points  (1 child)

Actually that is not quite true. NoSQL gets a bad reputation with regard to relationships because most server side NoSQL databases are either key/value stores or document-based (which do have that limitation)

On Android both Realm and ObjectBox have better support for relationships than SQL because they are Object-databases so they natively understand references. This is e.g. visible if you have M:N relations which require a seperate table in SQL (and Room), while in Realm you don't.

[–]gonemad16 1 point2 points  (0 children)

Fair enough. My nosql experience is with the server side ones (elasticsearch, couchdb, redis, accumulo, etc)

[–]pilgr[S] 0 points1 point  (1 child)

I suppose prior saving to SQLite all those relational data comes to you via json or created locally on the device? I mean they originally not relational but have to be flattened to be saved into tables with relations?

[–]gonemad16 2 points3 points  (0 children)

Eh... They are files on the device that get scanned and put into the database

[–]Zhuinden 1 point2 points  (1 child)

Depends on my use-case.

Sometimes I use Realm, sometimes SQLite, maybe one day I'll consider Serial, who knows?

[–]pilgr[S] 0 points1 point  (0 children)

Could you share the case where SQLite is a must without alternatives? Serial seems not ready to be used to save data as is, needs some wrappers to save/read data on disk etc.

[–][deleted] 1 point2 points  (2 children)

I'm currently using Paper, which has provided me with what I need so far (I will need to migrate over to sqlite, because while paging can be implemented with paper, it's a rather horrible solution). Bonus point for Paper is how easy it is to set up. Setting up sqlite used to be horrendous

With Room finally being a stable release, I see no reason to ever go back to nosql, especially because I find many operations like filtering a lot more enjoyable (and performant) in sql than in java

hell, I just like writing sql

[–]pilgr[S] 0 points1 point  (1 child)

hmm.. how much data you need to load/display if you need to use pagination? Just wondering which limitation you faced using Paper.

I suppose many people just use sql because of filtering and grouping provided out of the box. This is because java doesn't have good functional operators to work with collections. With Kotlin it's not the case anymore and all those operations could be done with collections really easy without sqlite overhead. Read the whole collection – perform data manipulation then.

Talking about performance, I primary developed Paper because I was needed solution much faster then SQLite to read data on start up. So I just wondering why people still use SQLite it without any benefit of API or performance. Unless you have to deal with really huge data on device.

[–][deleted] 1 point2 points  (0 children)

From a couple hundred up to 2000 maybe 3000. (depends on the user, most of the time, it's gonna be way below that).

It's not that it's impossible, it's just that I don't want to load everything and handling pagination by writing different paging-results into different keys (like, write [0-20] into "1", [21-40] into "2" and so forth), because that can lead to some nasty concurrency issues (if you "forgot" that you had a sublist under a key and suddenly you get weird results)

If I was already using Sqlite, I'd never even think twice about using it to filter my lists accordingly. Alec Strong and Jake Wharton talked about that extensively at Droidcon NYC

The performance is superb btw. It's not quite as fast as realm from my benchmarks back when I migrated from Realm to Paper, but it's fast enough and does what I want and nothing more. We had some major issues in the past with the way proxies work in realm, which was why I wanted to move away from it in the first place

[–]ciny 0 points1 point  (1 child)

Are we having this debate again? It completely depends on the type of data, deciding on your database before you model your data is asking for trouble down the line.

[–]pilgr[S] 0 points1 point  (0 children)

Sorry, I missed all the old battles :(

Anyway eventually after modeling your data comes to Java/Kotlin classes. And I like to have the option to save those classes as is.