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

Question

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

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

Таким образом, каждый жанр будет иметь эти три URL-адреса.

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

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

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

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

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

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

Answer 2

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

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