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

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

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

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

РЕДАКТИРОВАТЬ: я только что заметил этот вопрос: Core Data vs SQLite 3. Я предполагаю, что мои вопросы таковы:

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

iphone sqlite core-data
person Don    schedule 08.05.2009    source источник
comment
Отличные ответы, спасибо - я использую всю эту информацию в нашем следующем обсуждении дизайна.   -  person Don    schedule 08.05.2009
comment
Просто в качестве обновления мы использовали Core Data; Я действительно рад, что мы это сделали. Одни только способности к сбоям сделали это стоящим, но, кроме того, есть много преимуществ. Я бы посоветовал любому, независимо от уровня владения языком SQL, выбрать Core Data. Кривая обучения неглубокая, а таких преимуществ, как сбой, уникальность, KVO / KVC и преобразование хранилища в объект, много.   -  person Don    schedule 29.07.2009

Ответы (3)


arrow_upward
19
arrow_downward

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

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

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

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

person Barry Wark    schedule 08.05.2009
comment
Существующий интерфейс - это приложение .NET 1.1, поэтому повторного использования там нет. Мы будем использовать его в качестве модели в приложении MVC, и это заставило меня задуматься об этом. Метаданные, загрузка только одного объекта и NSPredicate - все это отличная информация! Спасибо. - person Don; 08.05.2009

arrow_upward
7
arrow_downward

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

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

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

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

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

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

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

person mmc    schedule 08.05.2009
comment
Спасибо за вклад. Да, первоначальный дизайн был разработан с учетом SQLite, но еще ничего не началось, и если Core Data, например, упрощает реализацию табличных представлений, то это достаточно рано, чтобы мы могли отключить его. - person Don; 08.05.2009

arrow_upward
2
arrow_downward

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

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

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

= Майк

person Community    schedule 08.05.2009
comment
Хороший момент - не знаю, почему я подумал сначала спросить здесь. KVO и привязки - это как раз те преимущества, которые мне не приходили в голову, и это огромные плюсы. - person Don; 08.05.2009