I am coding a questionnaire iphone app (maybe ipad eventually but not yet). People will go out into the field and ask questions. In SQL terms I picture the structure thusly : THIS_APP_DETAILS_TABLE (just one row of data to be stored) id_details_primaryKey | your_name | team_leader_name | team_leader_id | other_details.... RECORD_OF_ANSWERS_TABLE (many rows of data to be stored) id_answers_primaryKey | name | answer_1 | answer_2| answer_3 | etc etc The app would store the answers to disk and also display them in a table and allow them to be edited. Would this be better implemented as core data or as fmdb? (which would mean I need to learn core data as I am from a SQL background and have never used core data). Do you agree that 99% of the time core data is the best way to code database driven apps rather than fmdb (or even raw mysql_lite) ? I ask that question as it does seem to be the prevailing answer when I googled it, but I want to be sure before learning an alien and proprietary data structure from scratch. Basically I don't want to discover I chose the wrong camp after I put all the work in.