В конце концов получается, что чаще всего для реализации каки-то базовых функций для работы программы (работа с локальными данными, работа с графикой) возращаемся к использованию решений, которые предоставляет компания-разработчки OS, в нашем случае Apple.Так что все эти FMDB от лукавого :)

Аналогично :) Тоже пришли с веб-разработки, с .NET. В подавляющем большинстве случаев сначала проверяем данные на наличие. Хотя, конечно, бывают ситуации, когда это не нужно. Что касается Core Data, то здесь все проще, мы реализовывали в дополнительном слое данных метод, который при вставке проверял наличие определнного ключа (если нужно). То есть сами реализовывали проверку на primary key. Лагов не замечали, ибо работали с памятью, а не с диском.

Используем Core Data. Это известный ORM, подход и работа с ним отточена, доступен сразу. Да, Core Data немного неповоротливый зверь, но только в начале пути разработки, потом начинаешь понимать почему лучше его использовать. Несколько раз столкнулся с ситуацией, когда коллеги по команде настояли на работе с FMDB, а потом (когда модель данных стала сложной) задумывались перейти обратно на Core Data, но отказывались от этой идеи и продолжали "есть кактус", так как фактически нужно было переписывать слой доступа к данным, причем весь. Дпугое дело,

З.Ы: прошу прощения за оффтоп :)

Тоже интерсует вопрос: чем так приглунулся именно FMDB? Личный опыт работы с этой библиотекой оставил только отрицательные впечатления, особенно это касалось многопоточной работы.