I want to use a custom class that could handle querying easily. Are there more convenient ways in handling database in Objective C? Can you suggest open-source library or class that do this? Thank you for your answers in advance!
Not an inbuilt class but take a look at FMDB that makes it nice and simple!!
https://github.com/ccgus/fmdb
FMDB is a nice library I have used a lot with success.
FMDB - Github
FMDB - article
Have you had a look at Core Data? It can persist Obj-C objects to a SQLlite database.
Basically Core Data is an Obj-C <-> SQLite object mapper, which allows you to design your database schema in Xcode and work with the data as with normal Obj-C objects.
Xcode will provide you with visual database schema editing as well as code generation. This way you get typed classes for all tables in the database, which I find a great help (auto completion, compile-time checking, etc).
In addition to this, Core Data can take care of data migration for you. Say that in version 2.0 of your application, you want to store your data a little bit differently. You can then define a mapping between your own model and the new model, and the migration will take place as soon as your data context is loaded.
If you want to go the Core Data path or learn more about it, I recommend starting with a tutorial and checking out the sample code.
Easy to use object oriented sqlite wrapper that I created:
https://github.com/Nortey/TankDB
At the moment, its not meant for heavy duty queries or bulk updates. For that I would take everyone else's advice on FMDB. TankDB is more suited for beginners.
Related
I am migrating with a project from Android to iOs. I am totally new to xCode and got already only some practice with Swift (o.w. I am just new with programming for iOs)
So I need help or simple explanation about local databases on iOs.
I've read about CoreData and about SQLite for iOs. I know that CoreData is "not just a database!" and I can't ask question about CoreData vs SQLite".. But I have to.. I try to understand but it's not written so clearly and simply as I need. If SQLite isn't naturally supported by xcode and iOs is it still safe to use it? Is it good to use CoreData when u need it only for local database?
So, what should I use when I need to store data on my phone and my database records on a local device won't be even more than 50000? The data will come from Server (JSON) and some of it from the device measurements
You can use both SQLite and Core Data. They are both widely used and you will not have any issues using them. If you want to use SQLite I would suggest using FMDB because it will make using the SQLite database easier. Core Data is very performant but you say you will not have a ton of data so it could be overkill and it is a bit verbose to use.
I think SQLite has an advantage if you want your server to be able to send you a straight up SQLite file as a download. SQLite is supported everywhere so it is easy to contruct a database on the server and send it over to the your phone as a file. Core Data is only supported on iOS so you will have to translate the information from your JSON, but you stated that you will already be doing that.
Personally, I think Realm is the easiest local database to get set up for iOS. I was able to add it to some of our code bases surprisingly fast and they have good documentation. They have a pretty big community and it is easy to get help as well as a wealth of tutorials on how to get started. Realm is also cross platform so you could use the same database in your Android app. If you are familiar with database ORM's for Code First database approaches then you will feel at home with Realm.
At the company I work at we use all three in our production apps, so it is merely a question of taste and other requirements outside of you control. All three will do what you want to do.
From the Apple Reference
What is Core Data?
Core Data is a framework that you use to manage the model layer objects in your application. It provides generalized and automated solutions to common tasks associated with object life cycle and object graph management, including persistence.
From this you can see the essential difference between Core Data and a database, such as sqlite; Core Data deals with objects. Persistence of those objects, while a common use of Core Data, is not compulsory. The Core Data framework can make use of different backing stores and sqlite is one of the most common stores.
When you deal with a database you have to think about tables and rows and you have to handle the conversion between the row data and your in-memory object. With Core Data, your model objects can subclass NSManagedObject and you can persist and restore them directly with Core Data.
With a database you can use foreign keys to relate rows between tables and you typically use a join or another query to obtain the related data. With Core Data you can simply assign the reference to the related object to a property of the first object e.g. employee.manager = someOtherEmployee and Core Data will manage the relationship for you when you persist the data. When you retrieve the data you can refer to employee.manager to get a reference to the manager object without needing to explicitly perform a query/fetch; Core Data will retrieve the object from the backing store automatically if necessary.
Unless you need complex queries or joins, you probably don't need sqlite. There is a bit of a learning curve with Core Data, but the first hurdle is understanding that it isn't a database and you shouldn't treat it like one.
The advantage of using something like sqlite can be portability; a database and queries that you are using in an Android app or website can be used in an iOS app.
To give you an idea of how Core Data could work in your situation;
Your data is coming as JSON objects, so using Swift 4 Codeable you can easily convert that JSON into a collection of Swift objects.
Xcode will create the Core Data Entity objects for you based on your Core Data model.
All you need to do is add extensions to these classes to implement Codeable and then you can persist your JSON data locally with virtually no additional code.
What the best way and how to work with multiples tables in iOS project and does FMDB supports relationships between tables?
Should I use Coredata or the FMDB wrapper?
Whatever you want to do, you can use either Core Data or FMDB + SQLite.
Basically, if one of the follow is true, I suggest using SQLite.
Performance is really important
You already have a huge SQLite database from elsewhere
You plan on making the database cross-platform somehow
Have a look at this blog post to read about the difference between SQLite and Core Data.
However, in most cases Core Data is a better way to go. Core Data is a great framework that helps you keep your consistency (using object graphs) and is really quite easy to use. It has received a bad rep for its performance, but it is actually not that bad. For instance, over-fetching is a common thing that is used to improve performance. This means fetching lots of data and then filtering out the data you actually want. This works great in iOS devices since their RAM is actually really good these days. Use it!
Also, if you plan on using Core Data, you should understand that it is NOT a wrapper for SQLite. You should not be thinking about tables like you normally would. In Core Data you have an object graph with entities instead of tables.
Conclusion:
Use Core Data unless you already have a SQLite database form elsewhere OR performance matters a lot (and I mean a lot).
There is no one good question for this. It's depends on project.
In my opinion if you have already some data which you want to import to the application, and you will facing huge amount of data in your database, you should go for pure sqlite (and maybe FMDB).
If you are connecting to REST, want to use TableViews, starting from empty database CoreData will right answer for you.
FMDB is only a wrapper on sqlite so it will have relations, because sqlite has.
I've been working with sqlite database in my iOS app for data persistence, and I'm now trying to decide if it is worth to learn Core Data. I've been reading some documentation and posts regarding its pros and cons, but I find that deciding when to use Core Data or Sqlite is not so clear (for example, Core Data VS Sqlite or FMDB…?).
I need some guidance to know if I should learn and use Core Data, or using Sqlite is enough for me:
Already having sqlite scripts, is it possible to build a Core Data model from data in sqlite database? Afaik, (correct me if I'm wrong) you can use sqlite to persist Core Data objects, but is it possible to operate in reverse?
Is it appropiate Core Data for handling several users data? I need to take into account that different users could log in into the app in the same device.
Thanks in advance
Core Data is a wonderful framework but while it generally uses SQLite behind the scenes, you shouldn't think of Core Data as a database engine, but rather more of an object persistence framework. If you've got a lot of SQL code (especially bulk updates and the like), it might not be worth converting to Core Data. But Core Data has lots of wonderful performance optimizations, iCloud integration, etc., so it's worth examining in greater detail.
If you want background on Core Data, I'd suggest the Apple video Working with Core Data.
If you just want to simplify your SQLite code, check out FMDB.
In answer to your questions:
Already having sqlite scripts, is it possible to build a Core Data model from data in sqlite database? Afaik, (correct me if I'm wrong) you can use sqlite to persist Core Data objects, but is it possible to operate in reverse?
You generally have to redefine your Core Data model. It cannot just open your existing SQLite database (though once you define your model, you could write code to transfer the data from SQLite to Core Data).
Is it appropiate Core Data for handling several users data? I need to take into account that different users could log in into the app in the same device.
Yes, you could. You'd have to define your model to handle this manually, though (e.g. add a user identifier field and manually code predicates/filters results accordingly, much like you'd have to do in SQLite).
AppsDev,
Only you can judge whether to use Core Data or to stick with SQLite. As you've referenced my answer above, you know my view -- use Core Data. Let me put it in your context.
The big win is the family of abstractions that come with Core Data and how they map onto the Objective-C object model. This is something you have to handle manually from a SQLite application. (Can you do it? Yes. You will, though, most likely make a custom interface that is tuned to your SQL schema. It will have little reusability. This is a long term problem.)
As to the question of predicates versus SQL queries, this is a difference in world view. That said, as predicates can be applied to both NSSets and NSArrays, they have a utility beyond that required by Core Data. Knowing how to use predicates will be of value. For example, you could easily perform a query to get a collection of records and then use predicates to filter them, say for the search of a table view.
Everyone needs to pick when they are ready to embrace a specific pattern. SQL experts, unsurprisingly, like to stick with what they know. Dynamic language aficionados will choose differently. For iOS/OS X, embracing the dynamic language path will have ever increasing value to you as a developer.
Hence, my recommendation remains: use Core Data.
Andrew
I have a new iPad application that is data driven (read, delete, create, update) and requires data persistence on iPad devices that are installed the application. There are about 10 tables for that application; those 10 tables are relational in some ways (one to many; many to many; and stand alone). I am new to data driven application with iPad.
I do not know whether I should follow the Core Data approach or SQLite approach. Which approach is the better and real-world oriented? Please advise. Thank you very much.
My advice is try both; sketch out two simple versions of your app, one with each implementation. Of course Core Data uses SQLite as storage behind the scenes, but it is much more than that. In my view it's a very complex, clunky beast to wrangle, but it is about modeling and persisting objects that have attributes, it can help a lot with consistency when you delete an object that's involved in a relationship, and the NSFetchedResultsController is helpful for populating a UITableView in a memory-efficient way. With SQLite it's just a database and that's all it is; you have to do all the work, but there are nice Objective-C front ends, and you are completely in control rather than having to do everything in Core Data's very strange way.
There's a short section of my book that demonstrates a tiny Core Data app, and even though it's tiny you can see I spend a lot of time banging my head against the wall of Core Data's special way of doing things:
http://www.apeth.com/iOSBook/ch36.html#_core_data
The previous section has a few lines showing how simple it is to fetch data from a SQLite database with a nice Objective-C front end:
http://www.apeth.com/iOSBook/ch36.html#_sqlite
I recommend that you read a book about Core Data before you commit yourself to it. There are several good ones. I'm not saying it's bad, but it is not at all a beginner technology and you really need to know what you're in for.
You are on the right track with Core Data in my opinion, what you need to ask yourself is how your data is being used against the benefits of each approach. Core data lets you update and write data using data types like NSDictionaries which do not require any outside of the box techniques to handle and write data like SQLite does. SQLite does work and can work how you want it to, but in my opinion using a third party wrapper is just one more step to take to achieve something that is already native.
Just curious if we can access the core data database through sqlite queries. On the process of searching, I've found Chris Miles' post for debugging core data with sqlite. Here, he points out that we can use the terminal to input sqlite queries and then actually access the core data database.
Kindly clarify if this is possible through objective - c code. If this can be done, may I ask some links for good tutorials I can study on. Thanks!
You can certainly make C sqlite3 calls from inside Objective-C methods. However, if you've gone to the trouble of defining your data model in Core Data and creating a managed object environment, it's hard to imagine why you would want to circumvent that.
Consider also that there's no guarantee that the current table layout under Core Data will stay the same with the next iOS release, so anything your assume about the storage is fragile.