Хранение списка URL-адресов по категориям - Sqlite DB, XML или pList? Дизайн структуры?

Question

Эй, ребята, я хочу сохранить категоризированный список URL-адресов. Это потоковое интернет-приложение, поэтому я хочу иметь как минимум три ссылки для каждого жанра:

• бесплатный потоковый URL с рекламой
• потоковый URL премиум-класса со скоростью 128 кбит / с
• потоковый URL премиум-класса со скоростью 256 кбит / с

Таким образом, у каждого жанра будут эти три URL.

Для потоков премиум-класса также существуют «географически локализованные» потоковые URL-адреса или «зеркала» для определенных глобальных областей. Например, если я нахожусь в Соединенных Штатах, я могу выбрать ближайшее расположение доступных зеркал для потенциально лучшего качества / надежности потоковой передачи.

Эти URL-адреса могут, хотя я часто сомневаюсь, измениться, и поэтому я хочу иметь возможность обновлять их, то есть хранилище не может быть только для чтения. Я не знаю точно, как мне хранить информацию, не говоря уже о том, в каком типе хранилища: sqlite db, XML или списки свойств. Я новичок во всем этом, поэтому извините, если кто-то из них глуп для такой ситуации, хе.

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

• Рок
• Лос-Анджелес
• Свободный поток
• Премиум-стрим - 128 кбит / с
• Премиум-поток - 256 Кбит / с

Но я думаю, что база данных / файл быстро станет огромной.

Полагаю, у меня также могут быть отдельные файлы / базы данных для бесплатных и премиальных потоков, учитывая, что премиум-пользователи, скорее всего, захотят слушать только премиальные потоки (, но все равно имеют возможность потока 128kbps или 256kbps в зависимости от их надежности сети ). Я мог бы тогда иметь возможность в настройках, какие потоки показывать; бесплатно или премиум. Это должно сократить размер.

Позже я хочу представить эти URL в виде таблицы и контроллера навигации. Корневое представление будет списком жанров, и, углубившись в каждый жанр, он покажет бесплатные или премиальные потоки. Местоположение (например, Лос-Анджелес) будет выбрано в настройках и не будет отображаться в виде таблицы.

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

Спасибо!

Answer 1

Если я вас понимаю, вы хотите:

Список жанров, каждый из которых содержит список местоположений, каждый из которых содержит список качеств, каждый из которых содержит набор данных (включая URL-адрес) или только URL-адрес. В любом случае, вы можете сделать это как список свойств, и он просто получит границу того, где вы хотите находиться со списком свойств, а не с базой данных.

SQLite находится на iPhone, доступ к которому осуществляется через стандартный API-интерфейс функции C, а Core Data - нет. SQLite, безусловно, позволит вам гораздо больше структурировать вашу базу данных и ваши запросы.

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

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

Answer 2

Что еще нужно учитывать, так это то, что для совместимости с устройствами до OS 3.0 Core Data (SQLite) на самом деле не подходит.

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