Основные данные против Sqlite или FMDB...?

теперь это может выглядеть как дубликат потока, но мой вопрос в том, что я прочитал много вопросов.. основные данные против SQLite 3 и другие, но эти 2-3 лет. Я также читал, что FMDB был разработан, поскольку основные данные не поддерживались на iOS, поэтому его больше не следует использовать. С другой стороны, я читал, что не следует использовать основные данные в качестве базы данных.

поэтому я серьезно смущен, должен ли я использовать основные данные для хранения объектов или нет!--6-->. Я имею в виду на каком основании я должен решить, что использовать? Есть ли какие-либо рекомендации, предоставленные apple или кем-то еще.. или это что-то, что придет ко мне со временем.?

35
core-data fmdb ios iphone sqlite

6 ответов

Анкит,

вот tl; dr skinny: используйте основные данные.

вот длинная форма:

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

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

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

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

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

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

Андрей

44

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

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

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

TL; DR:

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

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

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

этот в должности объясните off и top сайт для основной даты против Sqlite (FMDB)

8

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

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

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

6

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

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

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

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

1

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

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

0