What is the interaction between Objective-C and RDBMSes like SQLite?

I would like to learn how to persist data to a RDBMS from Objective-C, and I don't really know where to start to learn this. Do I learn a RDBMS? Do I learn data modeling?

I'm wondering are there techniques or special considerations when modeling the data as to not run into any pitfalls? I.e. are there rules of thumb like "don't subclass" or "always encapsulate your attributes."

In my limited experience it has been quite difficult to translate an Objective-C class into a relational database. It would seem that CoreData might get me started off on the right path, but it also seems like CoreData kinda just gives me a lot of things to take for granted (I'm curious to know what's going on under the hood with the SQL calls...). Or am I understanding this framework wrong?

I'm looking for any resources that would get me started down the path of better understanding RDBMSes and how Objective-C model classes typically interact with them for data storage.

EDIT:

In an effort to answer my own curiosity, I've picked up Joe Celko's SQL for Smarties as well as Beginning Database Design by Clare Churcher. Neither of them really gi开发者_StackOverflowve much by way of the interaction between controller classes written in non-SQL languages (in my case Objective-C), SQL, and the database. There's a missing link that I'm just not understanding...

---

Check out BaseTen https://bitbucket.org/mka/baseten/wiki/Home

---

Sorry it's taken so long to come back to you. What you are asking is not specific to Objective-C. My first introduction of connecting Object-oriented code to RDBMS was Enterprise Object Frameworks in NextStep. But since then, that idea has been copied in most object-oriented languages including Java and Ruby (see ActiveRecord).

Conceptually, on the programming side there is usually a entity class that is used to represent each row of a table. In some cases, such as CoreData or WebObjects, a map is used to create an interface between the application code and the database. Because of this map, a developer can use instances of the generic entity class to represent the data. Of course, many times that class is subclassed to added methods specific to a particular entity.

For example, say you have a table for contacts, which has a column for first name and a column for last name. Often in an application you want to display the full name. In a subclass of the entity class, one can add a method that returns the first and last name as a single string.

In other frameworks, such as ActiveRecord, I believe you must always have a subclass that represents each table.

Conceptually, I find Object-Oriented programming to align well with RDBMS.

Table (contacts) -> Class (Contact)

Row -> Instance of class (aContact)

Columns (firstName) -> Properties (aka instance variables, attributes) (firstName)

Relationships:

to-one (father) -> Properties (father, an instance of Contact)

to-many (emailAddresses) -> Array (emailAddresses, an array of instances of EmailAddress class)

Hope this answers your question better,