Вот как я в итоге решил эту проблему.
Хотя ответы Амории и М. Харрисона были верны, у них было одно предположение: после создания не только таблицы, но и каждая строка в каждой таблице всегда будут одинаковыми.
Проблема в том, что мой процесс предварительного заполнения базы данных «Животные» с использованием существующих данных (которые периодически обновляются) каждый раз создает новый файл базы данных. Другими словами, я не могу полагаться на создание связи между (статической) сущностью Animal и (динамической) сущностью Rating в Базовых данных, так как эта сущность может не существовать при следующей регенерации приложения. Почему бы и нет? Потому что я не контролирую, как Core Data хранит эти отношения за кулисами. Поскольку это хранилище резервных копий SQLite, вполне вероятно, что оно использует таблицу с отношениями внешних ключей. Но когда вы регенерируете базу данных, вы не можете предположить, какие значения получает каждая строка для ключа. Во второй раз первичный ключ для Lion может отличаться, если я добавлю лемура в список.
Единственный способ избежать этой проблемы - предварительно заполнить базу данных только один раз, а затем вручную обновлять строки при каждом обновлении. Однако в моем случае такой процесс не возможен.
Так в чем же решение? Ну, поскольку я не могу полагаться на отношения с внешними ключами, которые устанавливают Core Data, я должен создать свои собственные. То, что я делаю, представляет собой промежуточный этап в процессе генерации моей базы данных: вместо того, чтобы брать мои необработанные данные (которые являются текстом UTF-8, но на самом деле являются файлами MS Word) и создавать базу данных SQLite непосредственно с Core Data, я представляю посредника шаг: я конвертирую .txt в .xml. Почему XML? Ну, не потому, что это серебряная пуля, а просто потому, что это формат данных, который я могу очень легко разобрать. Так чем же отличается этот XML-файл? Значение хеша, которое я генерирую для каждого животного, используя MD5, которое я буду считать уникальным. Для чего нужно значение хеша? Теперь я могу создать две базы данных: одну для «статических» данных Animal (для которой у меня уже есть процесс), а другую для «динамической» базы данных Ratings, которую создает приложение для iPhone и которая находится в каталоге Documents приложения. , Для каждого рейтинга я создаю псевдосвязь с животным, сохраняя хэш-значение сущности животного. Поэтому каждый раз, когда пользователь открывает подробное представление Animal на iPhone, я запрашиваю «динамическую» базу данных, чтобы найти, существует ли сущность Rating, которая соответствует значению Animal.md5Hash.
Поскольку я сохраняю этот промежуточный файл данных XML, в следующий раз, когда будет обновление, я смогу сравнить его с последним файлом XML, который я использовал, чтобы увидеть, что изменилось. Теперь, если имя животного было изменено - скажем, опечатка была исправлена - я возвращаю значение хеш-функции для этого животного на месте. Это означает, что даже если имя животного будет изменено, я все равно смогу найти соответствующий рейтинг, если он существует, в «динамической» базе данных.
У этого решения есть еще один приятный побочный эффект: мне не нужно решать какие-либо проблемы с миграцией. «Статическая» база данных Animal, которая поставляется вместе с приложением, может оставаться встроенной в качестве ресурса приложения. Это может изменить все, что он хочет. В какой-то момент «динамическая» база данных рейтингов может нуждаться в миграции, если я изменю ее модель данных, чтобы добавить больше сущностей, но в действительности две модели данных остаются полностью независимыми.