Database in iOS App

You aren't going to use MySQL in an iOS app. You would have to write an online-only app that pulls data from a MySQL-driven website. In theory, you could use local storage in HTML5. If you want a self-contained app, use Core Data. Be patient.

TShirt wrote:

1 - Why do you suggest Core Data istead of SQLite3 ?

Because using native SQLite is a roll-your-own approach. Sometimes that is a good idea. I had an app that used native SQLite to access a pre-built database. Using Core Data for that is overkill and not necessary.

However, if this is data that you plan to update within the app, that is different. You would have to do a lot of work to manage your data and manage your tables. You can certainly do that, but then if you want advance your app and move into iCloud, you will have to re-do it all.

Core Data is written from a programmer perspective, not a database perspective. If you are thinking in terms of a database then it seems silly to go through all the hassle. But once you are writing your software and interacting with the user interface, it is much easier to deal with data as objects with built-in relations to other objects. Core Data is a lot of effort for a small project, but once accomplished, it will scale easily and with far less effort on your part.

2 - Why "Be patient" ? It's hard to implement what I need ?

Core Data is just difficult conceptually if you are used to working databases natively. In my example above where I used SQLite natively, I had an ulterior motive - I didn't understand Core Data. I still don't fully understand it because I haven't had time to work with it. But I'm making progress. I have made enough progress that I can definitely assure you that thinking from a database perspective is just going to hold you back. That perspective is easier to understand conceptually than Core Data, but harder to get a working, real-world app. That is, of course, the ultimate goal.