Эффективность основных данных

Является ли излишним хранить 4 типа атрибутов в 32-битном int в Core Data? Или я должен просто создать отдельный атрибут для каждого из них? (будет использовать логические операторы для установки/получения).

Я планирую добавить новую сущность к существующему объекту, который будет содержать от 200 до 400 элементов с примерно 14 атрибутами (включая атрибут «индекс» для целей упорядочения). Только один набор будет работать или просматриваться в любой момент времени.

Мне нужно будет поддерживать поддержку отмены (ссылка на Как повысить производительность вставки объекта Core Data на айфон?)

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

Кроме того, неразумно ли хранить набор из 400 объектов в постоянно растущем списке, который будет увеличиваться со скоростью примерно 1-3 объекта в неделю?

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


iphone core-data processing-efficiency
person Christopher    schedule 03.06.2012    source источник
comment
Просто для подтверждения. Вы можете хранить тысячи элементов в постоянном хранилище Core Data SQLite. Это работает хорошо.   -  person Adam    schedule 04.06.2012

Ответы (1)


arrow_upward
1
arrow_downward

Итак, вы говорите, что у вас есть 400 объектов с 14 атрибутами, которые вы можете либо хранить как отдельные целые числа, либо объединять в меньшее количество 32-битных (4-байтовых) значений?

400 х 14 х 4 байта = 22 400 байт

Это совсем не так много места. Если вы сократите это вдвое, вы сэкономите 11 КБ, которые, вероятно, будут ничтожны по сравнению с размером дополнительного кода, который вы будете генерировать для кодирования и декодирования этих значений.

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

Вы также можете прочитать о SQLite и о том, как он хранит значения, поскольку это то, что Core Data использует под капотом.

Моя интуиция подсказывает, что вы параноик, и ваш код немного не поможет. Хуже того, это будет отличный способ ввести действительно тонкие ошибки, когда вы забудете, что вы сдвигаетесь с расширением знака. (И я люблю писать битовый код!)

person benzado    schedule 03.06.2012
comment
Спасибо! Написание тестовой программы — хорошая идея. На ум приходит совет прагматичного программиста: не предполагай — докажи. Я также проверю документы SQL Lite. - person Christopher; 04.06.2012