I’m making a fairly simple application and I’ve got a settings menu that stores times and some boolean values. I have the application storing and retrieving data already but I started to wonder if SQLite was a bad choice.
I am assuming the answer is that I should’ve probably just used a pList for such few values. But if I’m comfortable with CoreData (and it’s already in place) is there a detriment to using SQLite over pList?
Also for sake of argument, lets say this database will hold a total of 20 items and at the most 2 tables.
0
-
Database migrations between core data models is difficult. Setting up a core data model (or any sql-like database) is like getting a tattoo.
-
The core data API is good but even seasoned veterans still struggle with it.
I am in no way suggesting core data is bad and it shouldn’t be used. I am just suggesting that in your case, you could easily avoid it, so you should.
-
Another thing to consider is that data retrieval from a pList is slower than core data fetches but I doubt this will impact you.
1
The difference between using plist, xml etc, and SQL whether raw or as one of the persistence options in Core Data is that the non-SQL solutions will load the entire persisted document into memory while SQL will only load what is needed at the moment.
In your case, it seems like you have so little data that SQL is over kill. You could use a plist generated from a dictionary, array etc or you could move you persistent store type to xml with Core Data.
Do make sure this is data you’re persisting and not, preferences, the later should be stored in user preferences.
1