Основные данные VS Sqlite или FMDB....?

Ответ 1

Анкит,

Здесь tl; dr тощий: используйте Core Data.

Здесь длинная форма:

Хотя вы можете использовать множество критериев для выбора между Core Data, ORM (FMDB) или прямыми вызовами sqlite, реальная стоимость этого выбора зависит от вашего времени, чтобы использовать его, поддержки Apple и использования других проектов. (RESTKit, который отображает службы REST на Core Data, популярен в наши дни.)

Следовательно, большой процент времени, скажем, 90%% (составленный stat), ответ на iOS будет заключаться в использовании Core Data. Зачем? После того, как вы приобретете его и создаете несколько вспомогательных методов, Core Data держит вас в постоянном вычислительном мире - графическом объекте Objective-C. Основные данные расскажут вам о том, как использовать динамический язык, который поможет любым другим аспектам вашего программирования iOS. Следовательно, вы более продуктивны. Не сражайтесь с рамкой.

Если вы используете большую, сложную базу данных SQLite и схему из другого приложения, тогда было бы экономически выгодно использовать либо FMDB, либо SQLite. Но я в этом сомневаюсь. Ваше время написания простого приложения командной строки на основе Mac для переноса базы данных в базовый БД данных является конечной и простой задачей. Вам почти гарантированно придется переписать большую часть бизнес-логики в Objective-C. (Да, С++ и Objective-C ++ - хорошие технологии. Действительно ли ваша бизнес-логика базы данных настроена на работу с ограниченным объемом памяти? Я так не думал.)

Основные данные получают рэп-рэп по производительности. Это действительно довольно быстро. Вам просто нужно использовать его иначе, чем использовать БД. В частности, вы почти всегда перехватываете данные из хранилища, а затем уточняете его с помощью предикатов непосредственно на разных наборах и массивах. На устройствах iOS, где вспышка удивительно медленная, эта стратегия перехвата особенно эффективна. У вас на самом деле много ОЗУ на этих устройствах, используйте его для повышения производительности. (Да, я знаю, что это явное противоречие с моим предыдущим постукиванием по переносимой бизнес-логике. Но на самом деле код, перенесенный с настольной или серверной среды, имеет так много неявных предположений о скорости диска, объеме памяти и реальности VM с резервным хранилищем, он просто не будет работать на устройстве с батарейным питанием, ограниченном памятью, с фанковой моделью памяти. [Это также не очень хорошо работает на устройствах Android.]). Вы также денормализуете свои данные для упрощения отображение его в различных виджетах iOS и Mac OS X UI. Есть несколько приложений, где Core Data будет медленнее, чем эквивалентная SQLite DB. Они были подробно описаны в других местах. Одна из основных претензий заключается в том, что задачи, в которых идентификаторы определяются базами данных выше по потоку, достигают производительности Core Data. Но это может быть несколько смягчено разумной индексацией и чрезмерной выборкой.

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

Другими словами, вам нужно было "использовать все" для использования Objective-C в iOS/Mac OS X, вы также получите некоторые важные преимущества в производительности от использования Core Data.

Эндрю

Ответ 2

Недавно я сам отправился в это путешествие и в конечном итоге опробовал все три. Вот что я узнал:

• Необработанный sqlite3
  • Низкоуровневый, полный доступ к базе данных. Нет абстракций. Очень многословие - для выполнения очень простых вещей требуется много кода.
• Основные данные
  • Очень высокоуровневый, построенный на абстракциях, ДОЛЖЕН использовать созданную Apple базу данных. Полезно для синхронизации iCloud и простого управления данными только для iOS. Трудно и опасно напрямую обращаться к базе данных и не должно использоваться для межплатформенных баз данных. По-прежнему требуется довольно много кода, чтобы делать простые вещи.
• FMDB
  • Высокоуровневая, очень абстракция дружественная, но не принудительная. Все равно получите полный доступ к базе данных, если вам это нужно. Предоставляет NSDictionary результата каждому элементу, автоматически присваиваемому приводом, к изменяемому варианту правильного типа данных (например, текстовые столбцы возвращаются как NSMutableString). Я закончил создание очень простого класса-оболочки вокруг него, чтобы абстрагировать его еще больше, поэтому у меня есть вспомогательный класс со статическими функциями, такими как selectAllFrom:(NSString *)table where:(NSDictionary *)conditions, который возвращает NSArray объектов NSDictionary. Это фантастика, чтобы иметь возможность делать такие вещи, как NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];.

В принципе, хотя Core Data могут быть полезны для простых приложений только для iOS, любой, кто заинтересован в использовании кросс-платформенных баз данных, должен оставаться далеко, далеко от него - Apple не заинтересована в том, чтобы сделать это легко, и это показывает.

TL; ДР:

• Не используйте raw sqlite3, если вы не делаете что-то чрезвычайно тривиальное.
• Основные данные отлично подходят для простых данных только для iOS, если вам удобнее блокироваться в нем.
• Если вам нужен полный контроль над базой данных, и вы не делаете что-то тривиальное, или вы создаете свое приложение для нескольких платформ, то FMDB определенно подходит.

Ответ 3

Я использую FMDB для всех моих проектов, которые сильно используют "INSERT s", а FMDB не устарел, Последний бой в Github был в ноябре прошлого года. Если вы идете с SQL, я рекомендую использовать FMDB.

Core Data подходит для 95% всех проектов, но если дело доходит до оптимизации для работы на стене. Если вам нужны преимущества Core Data (ООП,...), то используйте его. Если у вас много вставки, удаляется с помощью "WHERE" пользователя Sqlite (FMDB)

Этот POST объясняет удаленный и верхний сайт для Core Date vs Sqlite (FMDB)

Ответ 4

CoreData - это not только абстракция базы данных SQL. CoreData также выполняет управление графами объектов. CoreData может делать то, что FMDB просто не может сделать.

Как всегда: это действительно зависит от вашего варианта использования. Но в 99% случаев CoreData является правильным выбором.

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

Ответ 5

Как новый парень SQL, я собираюсь вставить мой .02:

В Core Data у вас есть немного "шаблонного" кода, который нужно ввести, прежде чем вы сможете фактически использовать свою базу данных. Вашему приложению требуется хотя бы одно из следующих: 1) Постоянный координатор магазина 2) Контекст управляемого объекта 3) Управляемый объект. Это коррелирует с сущностью, которая коррелирует с таблицей, если вы используете базу данных SQLite.

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

С другой стороны, у нас есть SQLite, который, на мой взгляд, намного легче понять. Для начала вам понадобятся: 1) База данных 2) Таблица или более (в зависимости от ваших данных) 3) Знание SQL - гибкий язык с упрощенным синтаксисом (запросы SELECT делают больше, чем вы могли изначально предполагать) 4) Объект, через который ваше приложение взаимодействует с SQLite.

Ответ 6

Core Data - это только абстракция объекта базы данных SQLite3. Это означает, что у вас будут устойчивые объекты, которые легко управлять для стандартных операций с базой данных. Вы также можете работать в транзакционном режиме и создавать основную структуру базы данных данных в XCode, создавая модели.

Если вы не хотите вручную создавать базу данных SQLite3 или сохраняемые методы, используйте Core Data.