Форум программистов, компьютерный форум CyberForum.ru

Программирование iOS/iPhone

Войти
Регистрация
Восстановить пароль
 
Рейтинг: Рейтинг темы: голосов - 10, средняя оценка - 4.80
smth
175 / 44 / 6
Регистрация: 23.06.2011
Сообщений: 245
#1

Муки выбора: core data или работа "напрямую" с sqlite - Программирование iOS/iPhone

03.03.2015, 00:38. Просмотров 1377. Ответов 4

Здравствуйте! Я новичок в разработке под osx и ios, но так как база на сях и плюсах была (когда-то давно), то идет это дело у меня довольно быстро. И пару дней назад передо мной встал следующий вопрос:

Ситуация: на iOS устройстве (пусть это будет фронтенд) требуется хранить (и периодически обновлять без обновления самого приложения) с сервера достаточно большое количество данных (тексты, картинки, некоторые служебные данные). На бэкенде (сервере) это все представлено обычной MySql базой данных с большим количеством таблиц и связей, и встала задача представить то же самое на iOS устройстве. При этом требуется сделать так, чтобы программа на устройство устанавливалась уже с начальным набором данных и дальше, по желанию пользователя, обновлялась с сервера. Основной режим работы приложения - оффлайн. Важно, что пользователь сам данные менять не может, т.е. все таблицы readonly и это, вроде бы, позволяет снять вопросы целостности связей, но мне непривычен такой подход.

Вопрос: что лучше использовать для хранения данных на устройстве, core data или прямую работу с SQLite базой? Прочитав несколько статей (в т.ч. большой кусок core data programming guide) я понял, что не могу принять решение по следующим причинам:
1: я привык работать с "нормальными" базами, где есть ключи, связи, индексы, уникальные значения итд и "нормальными" запросами к бд. В core data я половину из этого не нашел;
2: у самих apple написано "Core Data is not a relational database..." со всеми вытекающими. Насколько "надежно" доверять такой системе, если надо хранить не просто master-detail список покупок с соответствующим представлением в бд? Тут еще раз всплывает вопрос о том, что все таблицы readonly и, по идее, можно вообще наплевать на связи и положиться на логику сервера (что там все таблицы правильные и при обновлениях ничего не "перекосит").
3: процесс начального заполнения до конца неясен (программа должна устанавливаться с изначальным набором данных): сам механизм core data не позволяет подключить созданную и заполненную заранее базу SQLite. Как я понял, выходом тут является создать OSX приложение с core data, создать там пустую модель, заполнить ее данными и закинуть в iOS проект. Но тут мне вообще пока неясно, как совместить структуру на сервере (где есть ссылочная целостность, уники и тд, уже писал выше) и полученный SQLite файл со структурой, которую core data посчитает нужной (конечно, на основе моей схемы, но тем не менее).

На данный момент мне, конечно же, проще будет работать напрямую с SQLite (несмотря на то, что Apple обещает снижение количества кода на 50-70% при использовании КД), но, так как в принципе эта сфера мне нова, мне не хочется беспричинно пользоваться нерекомендуемыми (устаревшими?) технологиями. Поэтому прошу совета опытных в этой сфере людей.

И еще общий вопрос: на одном буржуйском форуме я запомнил фразу, что CoreData для OSX существенно отличается (по логике, не по коду) от CoreData для IOS, но дальнейшего развития эта фраза не получила. Объясните, пожалуйста, что имелось ввиду.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
03.03.2015, 00:38     Муки выбора: core data или работа "напрямую" с sqlite
Посмотрите здесь:

Objective-C Приведение типов, или как избавиться от "Warning"
Нужно разъяснение с Core Data
core data newManagedObject setValue:
Работа с sqlite
core data, две сущности
core data запрос на получение суммы атрибута, всех записей
Использование Core Data в статической библиотеке
Сервер / Game Center для онлайн игры "Шашки"
Objective-C Как записать данные в соответствующую категорию с Core Data?
Core Data проверка уникальности записи
Improve Core Data skills
Objective-C Работа с "вкладками" в самодельном браузере

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
После регистрации реклама в сообщениях будет скрыта и будут доступны все возможности форума.
Vorona
Peace 2 all shining faces
666 / 528 / 45
Регистрация: 05.03.2010
Сообщений: 1,271
04.03.2015, 04:09     Муки выбора: core data или работа "напрямую" с sqlite #2
Цитата Сообщение от smth Посмотреть сообщение
пусть это будет фронтенд
ну для начала это называется клиент, а не фронтенд

далее, все же советую использовать CoreData - задача впринципе довольно тривиальная и никаких минусов в сторону ее не наблюдаю
Если знакомы с понятием ORM, то CoreData это что-то вроде этого, нормальная sqlite БД, с которой вы работаете при помощи объектной модели (более понятной) и скрывающей все ненужные запросы
Схема красиво строится как в графическом так и в табличном видах, указываются все связи, индексирования, правила удаления связей, кастомные выборки при обращении к полю и тд.
Кастомные запросы - да какие угодно, только при помощи NSFetchedRequest
Можно активировать дебаг мод и смотреть какие sql запросы делает CoreData, когда вы кормите ей fetchedRequest и смотреть уже подходит вам запрос или нет
Насчет доверия - не слышал, чтобы кто-то ей не доверял, бывают только те кто не любят что она чуток нагроможденная
Процесс начального заполнения - заполните базу на iOS и положите в свое приложение, тут есть небольшой нюанс почему так - CoreData чуть по-своему создает сущности в БД и связи между ними (с приставками Z и еще свои особенности), потому да, если брать руками заполненную базу, то так просто не выйдет
зато выйдет программно получить json или в другом виде данные, и просто положить их по таблицам в базу при помощи CoreData
в любом случае вы делаете синхронизацию, на которой все данные тянутся, так вот просто синхронизируетесь и потом эту базу вшиваете в апп, а при старте копируете в нужное место и вуа-ля, у вас при первом старте появится готовая база

Вообще странно, что вы до сих работаете с голыми sql запросами, всмысле это конечно хорошо, но зачем так усложнять все, когда есть такие ОРМ как Hibernate или на других языках\платформах другие.

Лично мы в команде использовали чистый sqlite только однажды, когда писали миграцию с созданной при помощи CoreData БД, для обновленного аппа, который обращается к sqlite базе при помощи webSQL

В любом случае, если все-таки решите использовать sqlite или попросту CoreData не подойдет, то вот вам статейка с хорошего ресурса
и библиотечка для работы с sqlite
http://ccgus.github.io/fmdb/
https://github.com/ccgus/fmdb
smth
175 / 44 / 6
Регистрация: 23.06.2011
Сообщений: 245
04.03.2015, 18:41  [ТС]     Муки выбора: core data или работа "напрямую" с sqlite #3
Vorona, спасибо!

С ORM знаком не был, но уже прочитал, что это такое. Раньше (писал на шарпе + MSSQL) делал всю работу с бд руками, несмотря на встроенные возможности студии. Наверное, если бы не неудобный (для меня после шарпа) obj c, я бы и тут сторибордами не пользовался. Буду разбираться.

В CoreData я, видимо, пока не дошел до этапа проектирования связей и ключей/индексов. Если есть возможность, дайте ссылку, где можно про это почитать, так как на apple developer я нашел раздел про связи и все.

В общем, я за грамотный подход, и, если это можно реализовать так, как эппл советует - буду реализовывать, главное, чтобы было, чего читать.

И еще вопрос: если некоторые причины, все-таки, вынудят меня использовать sqlite (а есть одна - портирование продукта в дальшейшем на андройд), какие негативные последствия может это повлечь? Вопрос теоретический, так как для меня не проблема сделать разные бд под разные устройства и потом заполнить их скриптом с сервера.

Добавлено через 2 часа 1 минуту
Основательно погуглил по поводу уникальности данных и, кажется, начал понимать: все то, что я раньше возлагал на субд (связи, уникальности, триггеры) теперь в большей степени (не все, конечно) должно проверяться на уровне приложения, так?
Vorona
Peace 2 all shining faces
666 / 528 / 45
Регистрация: 05.03.2010
Сообщений: 1,271
04.03.2015, 22:20     Муки выбора: core data или работа "напрямую" с sqlite #4
Насчет ресурсов, то

Apple CoreData Guide – https://developer.apple.com/library/...mingGuide.html
Stanford iTunes U – https://itunes.apple.com/ua/institut...rd/id384228265
поищите Stanford University iPhone programming - отличные курсы чтобы начать

Ну и парочка просто статей –
http://www.objc.io/issue-4/
http://www.raywenderlich.com/934/cor...etting-started

Насчет проблем портирования приложения на Андроид устройства – ммм даже не знаю
впринципе ничего сложного, код новый прийдется писать в любом случае, зависит от того сколько как таковой работы с базой
мы, например, особо не зацикливаемся на этом, хотя пишем довольно большие CRM\CLM системы и salesforce на бекенде
тут немного другой вопрос уже, а именно насколько дешевле обойдется разработка при помощи удобных инструментов, которые хорошо выполняют свои задачи на своей оси и в своей категории, нежели писать все старым добрым sqlite, но при этом реально выдумывая велосипеды и маппинг sqlite базы на объектную модель (а вам его 100% прийдется делать, иначе приложение превратиться в ужаснейший кошмар с legacy code)

Честно, я за то, чтобы выбирать готовые удобные решения, которые были придуманы не зря и которые решают огромное количество monkey job задач, при помощи которых разработка и поддержка кода будут в разы быстрее и вообще реальны

Но снова таки, конечно, если проанализировав задачу, вы понимаете что удобней будет использовать sqlite в чистом виде, нежели всякие громоздкие обертки и их изучение отнимает лишнее время, то тогда ответ очевидно в пользу чистого sqlite

Насчет задач субд, то напримр CoreData решает многие эти вопросы на этапе проектирования базы, описание связей тригеров и т.д.

В андроиде тоже есть неплохие ОРМ, конечно, не настолько как CoreData, но тоже позволяющие хорошо мапить данные

p.s. а насчет C# и MSSQL, то вроде есть NHibernate - аналог Hibernate, только для .NET
smth
175 / 44 / 6
Регистрация: 23.06.2011
Сообщений: 245
11.03.2015, 20:02  [ТС]     Муки выбора: core data или работа "напрямую" с sqlite #5
Вчера обновились требования к программе, и, видимо, прийдется отказаться от Core Data в пользу SQLite: хоть я и всячески пытался избежать возникновения такой ситуации, но выбора нет: в процессе работы требуется изменять структуру бд (добавлять новые таблицы и связи) без обновления самой программы, чего, как я понял, Core Data не умеет. Значит, буду использовать fmdb, еще раз спасибо за статью и ресурс!
Yandex
Объявления
11.03.2015, 20:02     Муки выбора: core data или работа "напрямую" с sqlite
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru