Когда * not * использовать тип Core Data Transformable?

Я понимаю, что использование типа Transformable - это простой способ хранения массива или любого настраиваемого объекта в Core Data. Я хотел бы знать, когда нужно не использовать Transformable, но вместо этого нужно создать другой объект и использовать отношения To-many.

Скажите, если это массив строк, существует ли максимальное количество элементов или максимальная длина строки, что может вызвать значительную проблему с производительностью?

Ответы

Ответ 1

Я хотел бы знать, когда нельзя использовать Transformable, но должен вместо этого создайте другой объект и используйте отношения To-many.

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

Вы редко используете Core Data для хранения структур данных, таких как массивы или словари, потому что Core Data в основном используется не для хранения/сохранения, а для моделирования/моделирования. Это бесполезно для моделирования данных, чтобы превратить структуру данных в большой, не требующий логики блок данных.

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

В ответ на ваш основной вопрос:

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

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

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

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

Ответ 2

На самом деле все зависит от того, как вы хотите использовать данные, описываемые трансформируемым атрибутом.

Core Data создаст столбец blob в вашей базе данных SQLite под капотом, поэтому практически невозможно выполнить какой-либо реальный поиск или отсортировать атрибут.

Обратное описание данных, которые вы хотите сохранить с помощью логического объекта (через отношение "многие" ), позволит вам использовать функции поиска и сортировки.

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

Что касается размера, вы можете сохранить столько данных, сколько пожелаете в блобе, это неограниченное. Это опять же снижает производительность такого дизайна, где (особенно на устройствах iOS) ввод-вывод очень дорог, а память ограничена, ваше приложение может просто не в состоянии прочитать данные из магазина и в память (люди попробовали приклеивать фильмы, в магазинах CoreData SQLite).