Опасения по поводу основных данных

Question

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

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

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

Стоит ли делать решительный шаг и использовать Core Data или мне следует придерживаться SQLite?

Answer 1

Как уже говорили I и другие , Core Data на самом деле является структурой управления объектными графами. Он управляет отношениями между объектами модели, включая ограничения на их мощность, управляет каскадным удалением и т. Д. Он также управляет ограничениями на отдельные атрибуты. Базовые данные просто случаются , чтобы также иметь возможность сохранять этот граф объектов на диск. Это может быть сделано в нескольких форматах, включая XML, двоичный и через SQLite. Таким образом, Core Data действительно ортогональна SQLite. Если ваша задача связана со встроенной базой данных, совместимой с SQL, используйте SQLite. Если ваша задача заключается в управлении уровнем модели приложения MVC, используйте Core Data. В конкретных ответах на ваши вопросы:

1. Нет волшебства, которое может автоматически импортировать сложные данные в любую модель. Тем не менее, это относительно легко в Core Data. Использование подхода multi-pass и использование бэкэнда SQLite может помочь в использовании памяти, позволяя хранить только часть данных в памяти за раз. Если наборы данных могут храниться в памяти, вы можете написать собственный постоянный формат хранилища, который будет читать / записывать напрямую в ваш прежний формат данных из Core Data (см. Руководство по программированию атомарного хранилища ).

2. Построение комплекса NSPredicate декларативно несколько многословно, но не должно вас пугать. Руководство по программированию предикатов - хорошее место для начала. Конечно, вы также можете писать предикаты, используя строковый формат, очень похожий на строковый формат SQL-оператора. Стоит отметить, что, как описано выше, предикаты в Базовых данных находятся на объектах и ​​графе объектов, а не на таблицах SQL. Если вы действительно хотите думать на уровне таблиц, придерживайтесь SQLite и напишите свою собственную оболочку.

Answer 2

Я не могу говорить с вашей первой точкой.

Однако, что касается вашего второго пункта, использование Core Data означает, что вам не нужно действительно беспокоиться о сложных запросах, поскольку вы можете просто притворяться, что все отношения уже правильно установлены в памяти (подробности реализации Apple в стороне). Неважно, насколько сложным может быть соединение в среде баз данных, потому что вы действительно не находитесь в среде баз данных. Если вам нужно получить четвертого потомка деда вашего текущего объекта, а затем найти имя и породу питомца этого ребенка, все, что вам нужно сделать, - это перебрать дерево объектов в коде, используя серию сообщений или свойств. Не беспокойтесь о соединениях или что-нибудь. Единственная проблема заключается в том, что это может быть очень медленно в зависимости от отношений ваших объектов, но я не могу точно сказать об этом, поскольку на самом деле я ничего не реализовал с помощью Core Data (я только что подробно об этом читал в Apple и других. сайты).

Answer 3

Если импортер данных из внешнего источника написан на основе той же базовой модели данных (для целевой / целевой стороны импорта) - ничто не будет концептуально другим по сравнению с использованием / обновлением тех же данных (через ядро стек данных из вашего фактического приложения).

Если вы создаете импортер данных без использования стека базовых данных, убедитесь, что вы хорошо изучили схему БД, которая была бы сгенерирована / ожидалась моделью на основе базовых данных. Там нет ничего волшебного - просто убедитесь, что вы следите за тем, как реализуются межсайтовые отношения и как хранятся иерархии сущностей.

Мне недавно пришлось создать импортер данных из базы данных Access в хранилище Sqlite на основе основных данных в виде приложения .NET. Как только моя основная модель данных была определена, я создал небольшое приложение, которое заполнило хранилище Sqlite случайно сгенерированными сущностями (включая все ожидаемые отношения). Затем я обратил внимание на то, как базовые данные на самом деле создали хранилище Sqlite для модели и как оно обрабатывает отношения, изучая сгенерированные и постоянные данные. Затем я реализовал импортер / преобразователь данных на основе .NET в соответствии с моими наблюдениями. В конце я получил идеальное хранилище данных, удобное для базовых данных, которое можно было бы открыть модифицированным из приложения, использующего стек основных данных в Mac OSX.