БД с разными источниками для хранимых данных
Проектируется приложение с использованием БД (SQLite). Предполагается, что пользователь может сущности задать иконку из предустановленных или загрузить свою локальную, а соответственно в БД для этой сущности нужно сохранить значение иконки. Вся сложность в том, что иконка хранится в разных местах (либо ресурсы приложения, либо локально).
Придумал несколько решений:
- Есть таблица entities и icons. У entities fk на icons. В icons храним пути до иконки и признак is_local (выбираем как грузить иконку).
а) Используем обычный id, тогда будут трудности при расширении массива встроенных иконок. Можно, конечно, зарезервировать некоторый пул id под встроенные (1000, например), но похоже на костыль.
б) Используем uuid, где для новых встроенных иконок генерируем новый и никогда не забываем. Ненадёжно, в коде присутствуют длинные константы, которые нельзя повреждать.
Общий недостаток: храним пути до внутренних ресурсов в БД предназначенной для данных пользователя.
- Тоже самое, но без FK. Тогда нет необходимости хранить в БД данные о ресурсах. Можно использовать int для встроенных, uuid для локальных.
Недостаток: нет FK.
- В принципе, частный случай #2, который повторяет #1, но выделить решил отдельно. Для предустановленных иконок используем отрицательные ID, а для пользовательских (в отдельной таблице) - положительные.
Недостатки: отрицательный ID (выглядит плохо), нет FK.
- Храним данные об иконках сразу в entities
Недостаток: нарушаем нормализацию, может быть много повторов одних и тех же длинных TEXT.
- Есть два вида icon_id у сущности. Один из них NULL, другой NOT NULL (проверяем триггером). FK на таблицу с данными о пользовательских иконок, а id встроенных мы знаем в самом приложении.
Недостаток: сложно для понимания, лишние столбцы.
Какое из решений обычно применяется в подобных ситуациях? Склоняюсь к #3 или #5. Может есть другие, которые я упустил?
Ответы (1 шт):
Вы никогда не пользовались линуксом?
Предлагаю вариант #6. Опереться на опыт организации иконок у FreeDesktop.
Хранить можно как в ФС, так и в БД.
Использовать FK не стоит. Всегда надо предусматривать такой вариант событий, что под какую-то новую фичу или приложение не найдется нужно иконки. Структура БД не должна мешать прогрессу.
Именовать иконки и обращаться к ним лучше всего по тем же принципам, как именование переменных. Номера иконок - это жесть. Вы же не хотели бы разбираться в коде, где переменные имели бы вместо названий номера!
Если иконок много тысяч, лучше собрать их в один архив. Только архив без сжатия и с индексированным списком файлов. Это чтобы иконками можно было пользоваться налету не распаковывая архив целиком.