I’m using an sqlite db to populate an ios app with data about irregular verbs — it’s a language learning app.
The db has 3 tables, verb categories, verbs, and verb elements. The last has one entry per verb termination, so 50-odd per verb. The total db is about 2,500 entries, each one has 3-5 short string fields.
My question is whether the best thing to do from a performance point of view is:
(1) – write structs to model the data, each with appropriate functions, and load the db into memory in the form of structs when the app initialises, OR
(2) – write functions to query the sqlite db on the fly for each new view
My guess is that (1) is much better for a small db of this size, but I thought I would consult your collective wisdom as I’m a novice. Thanks in advance for any advice.
Btw, this is a follow up question to one I asked about how to get data into an ios app:
2
Answers
Both solutions should be sufficient for your case.
When it comes to performance this is question on what you are measuring.
For instance when increasing memory consumption you have to understand that your app will more likely be terminated when in background. If user decides to take off 5 minutes and opens a game which loads immense amount of memory your application will more likely be terminated to get that memory for another application.
But again. Both solutions should be fine for the size you are describing here. Over time if this increases you may need to reconsider.
Also there is an option 3 where you can just hardcode these values directly into structures so you even lose initial load time. Just make a script or something that transforms your files with strings to source code.
Have you thought about CoreData? I use it for a small DB and it works fine. There is of course the learning curve of CoreData, but once you get over that, it does a lot of the work for you and has some integrations with SwiftUI as well. I am not saying it is more or less performant in any way, just that once over the learning curve, it is pretty easy to use and of course optimized by the Apple CoreData team.