Базовые данные против SQLite для опытных разработчиков SQL

Question

Мы начинаем разработку собственного приложения в программе для разработчиков iPhone Enterprise. Поскольку он близок к OS 3.0, мы пересматриваем наш оригинальный дизайн использования SQLite и использования Core Data. Вот еще немного информации:

• Существует устаревшее настольное приложение, которое оно заменяет. Мы будем повторно использовать существующую серверную часть.
• В настоящее время у нас есть база данных SQLite, созданная в качестве доказательства концепции. Это в основном урезанная версия существующей серверной базы данных.
• Мы будем загружать данные с удаленного сайта и сохранять их локально, где они будут сохраняться и должны быть. Мы только обновляем его, если он изменился, что будет каждый месяц или два. Скорее всего, мы будем использовать XML или JSON для передачи данных.
• В этом проекте есть два разработчика, и мы оба обладаем сильными навыками SQL, но ни один из них не использовал Core Data.

Мои вопросы: в чем преимущество Core Data по сравнению с SQLite, какая выгода в этом конкретном случае и оправдывает ли эти преимущества изучение новой структуры вместо использования существующих сильных навыков SQL?

EDIT: Я только что заметил этот вопрос: Базовые данные против SQLite 3 . Я предполагаю, что мои вопросы поэтому:

• Если мне нужно проверить, существует ли конкретный элемент или есть обновление, что легко с помощью SQL, все ли смысл в Core Data? Могу ли я загрузить первый объект в график и проверить номер версии, не загружая весь график?
• Если мы уже знаем SQL, оправдывают ли преимущества Базовых данных для этого одного проекта изучение?

Answer 1

Когда вы прочитали Базовые данные против SQLite 3 , вы знаете, что Базовые данные и механизм сохранения (в данном случае SQLite) в значительной степени ортогональны. Базовые данные на самом деле предназначены для управления графом объектов, и его основной пример использования - для компонента модели архитектуры MVC. Если ваше приложение хорошо вписывается в эту архитектуру, вероятно, стоит использовать Core Data, поскольку это сэкономит вам много кода в компоненте модели. Если у вас уже есть работающий компонент модели (например, из существующего приложения для настольных компьютеров), то Core Data не будет вам выгодна. Возможен гибридный подход - вы можете сделать свое собственное постоянство / запрос и построить базовые данные в хранилище памяти, которое вы заполняете результатом запроса, и использовать это хранилище в памяти через Core Data в качестве компонента модели для вашего приложения. Это не часто, но я сделал это, и никаких серьезных препятствий нет.

Чтобы ответить на ваши конкретные вопросы:

1. Вы можете назначить номер версии всему постоянному хранилищу и получить эту информацию через +[NSPersistentStore metadataForPersistentStoreWithURL:error:], даже не открывая хранилище. Конечно, также существует эквивалент +setMetadata:forPersistentStoreWithURL:error. Если вы хотите сохранить информацию о версии в экземпляре объекта, а не в метаданных постоянного хранилища, вы можете загрузить только один объект. Благодаря постоянному хранилищу SQLite Core Data отлично справляется со сборкой только того, что вам нужно.

2. API NSPredicate очень прост в освоении и, похоже, хорошо справляется с компиляцией в SQL. По крайней мере, для баз данных такого размера, который вы могли бы разместить на iPhone, это, безусловно, было достаточно (с точки зрения производительности) по моему опыту. Однако я думаю, что вопрос SQL против базовых данных слегка ошибочен. Как только вы получите результат запроса, что вы собираетесь с ним делать? Если вы создадите свой собственный объект, вам придется создавать экземпляры объектов, обрабатывать ошибки / уникальность (если вы не хотите сразу загружать весь результат запроса в память) и все другие средства управления графами объектов, уже предоставленные Core. Данные.

Answer 2

Похоже, у вас уже есть проект, разработанный с использованием SQLite, и у вас есть опыт в этой области.

Итак, суть в том, имеет ли смысл портировать этот проект, даст ли Core Data мне что-нибудь, чего у меня еще не было в моем первоначальном проекте?

Предполагая, что оригинальный дизайн был выполнен правильно, исходя из требований НА ЭТОМ ПРОЕКТЕ, это, вероятно, не стоит.

Но это не конец обсуждения. Есть и другие вещи, о которых стоит подумать: будут ли в моем следующем проекте такие легкие требования к базе данных? Нужно ли мне отправлять в ближайшее время, из-за сроков или бюджетных ограничений? Предполагая, что мне рано или поздно придется изучать Core Data, не имеет ли смысла делать это сейчас? Возможно, я заинтересован в переносе моего кода на Mac?

Ответы на эти вопросы могут привести вас к решению, что да, это действительно стоит того, чтобы вернуться, так сказать, к чертежной доске и узнать, что такое Основные данные.

Чтобы перейти к вашему последнему вопросу: каковы преимущества? Ну, Core Data - это абстракция вашей базы данных более высокого уровня, он также не зависит от хранилища данных (поэтому, если будущая версия iPhone будет отказываться от SQLite для встроенной версии MySQL ... маловероятно, но это пример), тогда Core Данные потребуют ОЧЕНЬ мало изменений в коде, чтобы он работал с новым хранилищем данных. Core Data обеспечит быструю переносимость на платформу Mac. Core Data будет управлять версиями вашей модели данных, в то время как если у вас нет инфраструктуры или рабочего процесса для управления ею, прямой доступ к SQLite не будет.

Я уверен, что другие ответчики могут предложить другие преимущества, и, возможно, некоторые веские причины, по которым НЕ следует связываться с Базовыми данными. Между прочим, в аналогичной ситуации мое решение состояло в том, чтобы перенести на более высокий уровень более новую платформу. Но в моем случае это был сторонний проект, и дата и бюджет поставки не были важны.

Answer 3

Не отвлекайте от этого форума, но вы можете найти больше респондентов с контекстно-значимым опытом на Apple iPhone DevForum.

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

При этом CoreData основывается на SQLite, и если вы пытаетесь использовать другие части системы совместно с вашими данными, например, используя KVC / KVO или привязки, вы можете быстро обнаружить, что эта функциональность стоит изучения.

= Майк