Многозначная таблица поиска

Мне нужно определить большой объем данных, которые будут храниться в приложении, и использоваться в качестве справочной таблицы. Например, у меня есть массив имен производителей, каждый из которых имеет код mfg. Каждый производитель может создавать разные продукты, каждый со своим собственным кодом.

A, 7 можно расшифровать, чтобы означать

```
Manufacturer: Apple(A)
Product: MacMini(7)

```

Я вижу несколько способов определить это, но я не уверен, что было бы лучше.

Вариант 1) #define эти константы в отдельном файле заголовка, например:

```
#define MFG_APPLE @"A"
#define MFG_DELL  @"B"

#define PRODUCT_MAC_MINI 7
#define PRODUCT_INSPIRON 2

```

Вариант 2) создайте объект словаря, заполненный объектами словаря, чтобы я мог проще индексировать их.

Вариант 3) использовать основные данные для создания базы данных этих mfg и продуктов и отношений.

 *Если предлагается вариант 2 или 3, есть ли простые способы предварительно заполнить эти структуры данных, а не жестко кодировать их для заполнения во время запуска программы?* 

Вариант 4) Создайте веб-службу, чтобы привязать ее обратно к серверу, где данные могут обновляться чаще. Запрос JSON отправит код mfg и продукта на сервер, где он может отвечать именами mfg и product.

Вы должны учитывать следующее: если база данных будет отправлена с помощью приложения, вам придется выпустить обновление для приложения каждый раз, когда база данных должна быть обновлена. Итак, вопрос в том, как часто вам придется обновлять данные? Если будет нормально обновлять базу данных раз в пару месяцев или, может быть, раз в год, отправка базы данных с вашим приложением может быть вариантом, если вам нужно обновлять ее каждый месяц или даже еженедельно, вам обязательно нужно разместить базу данных где-нибудь на паутина; освобождение обновления за такие короткие промежутки не представляется возможным.

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

По моему опыту, лучше всего размещать такую базу данных в Интернете, но при необходимости кэшировать ее для автономного доступа. Само приложение поставляется с копией базы данных, которая была обновлена в тот день, когда вы создали приложение для распространения. Каждый раз, когда приложение запускается и, возможно, один раз в день, если приложение никогда не уходит, он будет запрашивать веб-сервер для текущей «версии» базы данных. Если эта версия новее, чем та, которая поставляется с приложением, она пытается загрузить копию этой базы данных в свой локальный кеш и затем переключается на кешированную копию для будущих поисков. Если кешированная копия будет потеряна (кеши могут быть красными системой в любое время), она должна будет повторно загрузить ее. Тем временем он может использовать отгруженную базу данных, которая устарела, но лучше, чем ничего. Если загрузка невозможна (например, на устройстве недостаточно свободного места), приложение может захотеть делать онлайн-запросы напрямую, если пользователь в данный момент находится в сети, возвращается к устаревшей отгруженной базе данных, если он отключен, и повторите попытку для загрузки кеш-копии через некоторое время (возможно, в это время на устройстве будет больше свободного места).

Таким образом, в основном ваше приложение будет работать следующим образом:

1. START
2. Имеется ли локальная кешированная копия? Если NO Goto 6.
3. Локальная кешированная копия обновлена? Если НЕТ Перейти к 5.
4. Выполните поиск, используя локальную кешированную копию. Перейти к 12.
5. Удалить устаревшую кешированную копию. Перейти к 1.
6. Отгруженная база данных обновлена? Если нет Перейти к 8.
7. Выполните поиск, используя отправленную базу данных. Перейти к 12.
8. Загрузите обновленную базу данных.
9. Загрузка выполнена успешно? Если ДА Перейти к 4.
10. Пользователь в сети? Если NO Goto 7.
11. Выполните поиск с помощью веб-службы JSON. Перейти к 12.
12. END

Если вы только добавите больше записей в базу данных в будущем, но существующие записи никогда не изменятся, есть еще один, даже гораздо лучший вариант: у вас просто две базы данных. Один, который поставляется с приложением, и тот, который содержит только обновления (новые записи добавлены) после последней версии приложения. Это сокращает объем данных, которые необходимо загружать и кэшировать. В этом случае ваше приложение должно всегда выполнять два поиска: один в отгруженной базе данных (который всегда выполняется первым), и если там ничего не найдено, в загруженной кешированной копии, которая не содержит записей, уже найденных в отгруженной базе данных ( или непосредственно в Интернете, если кешированная копия недоступна, но в настоящее время у пользователя есть доступ в Интернет). Каждый раз, когда вы выпускаете новое обновление приложения, он получит новую полную копию базы данных, поэтому вы можете сбросить базу данных обновлений до нулевых записей и только продолжать добавлять туда новые записи (или вы можете хранить разные базы данных обновлений на сервере для разных версий приложений, в которые были отправлены разные базы данных, если вы не думаете, что это слишком много хлопот для управления).

База данных обновлений для загрузки может даже создаваться динамически сервером, что, конечно, будет лучшим вариантом. Например. после отправки приложения вы добавляете 3 поставщика и 30 продуктов в базу данных, и каждый поставщик и продукт имеет уникальный идентификатор (который увеличивается с каждой добавленной новой записью), тогда приложение может сообщить серверу, что самый высокий поставщик, которого он знает имеет идентификатор X, а наивысший продукт имеет идентификатор Y, и в этом случае сервер отправляет базу данных обновлений всем поставщикам и продуктам, чьи идентификаторы выше X и Y.

Все эти решения влияют на формат базы данных. Как правило, это очень похоже на работу для CoreData, но если вам нужны динамические базы данных обновлений, обновления должны поставляться в другом формате (JSON, XML, CVS или что-то еще, что сервер может легко сгенерировать) и преобразовать в CoreData на приложение после завершения загрузки, поскольку динамическое создание баз данных CoreData на сервере довольно сложно и определенно не рекомендуется.