Здравствуйте.
Разрабатываю, для домашних нужд, фотохостинг. Для каждой фотографий будет до 7 миниатюр. Мне необходимо сохранять габариты и размер миниатюр. С учетом, пути, в итоге, получается 28 атрибутов. И это только по миниатюрам. Кроме этого, есть дополнительные 15 атрибутов, характеризующие фотографию. В итоге, 43 атрибута. Нам мой малый кругозор, это очень много.
Пришёл в голову альтернативный вариант, а именно, вынести миниатюры в другое отношение.
photos
id | otherAttr
thumbs
id | photo_id | path | width | height | size
Этот вариант удобен в выборке по габаритам, но он увеличивает базу данных многократно. При добавление 1000 фотографий (а их больше будет), в отношение thumbs будет 7000 строк.
Что думаете вы? Какой из этих вариантов самый оптимальный? Наверняка, есть и альтернатива?
Спасибо
____________________________________________________________________________
Для приложения фотогалереи определился со структурой базы данных.
Получилась лаконичная схема, с возможностью объединения двух типов файлов - фото и видео.
Приемущества:
1) Без изворотов, разнотипные медиафайлы можно объединять в альбомы;
2) Для комментариев и закладок достаточно по одному отношению (таблице);
3) Миниатюры медиафайлов вынесены в отношение photos, что позволило схему привезти к 2НФ;
4) Отношение items упростилось на 5 атрибутов.
В результате, такую схему оказалось проще модерировать. В приложение предусмотрена функция выбора миниатюры по габаритам, соответствующих структуре отображения. Например, при отображение галереи в стиле justfield, система ориентируется на высоту изображения, и подбирает файлы с похожим размером высоты. Это позволяет не загружать тяжеловесные файлы.
Недостатки:
1) При добавление одной записи в items, в photos будет добавляться до 5 записей.
Сейчас сложно судить об этом недостатке. В скором времени, проверю этот пункт, записав в items от 1 млн. строк.
Простой
