Форум dkLab и Denwer
Здесь общаются Web-разработчики.
Генеральный спонсор:
Хостинг «Джино»

Как построить модель фотоальбома? (zetter)
Author Message
zetter
Заглянувший



Joined: 26 Oct 2005
Posts: 13
Карма: 0
   поощрить/наказать


PostPosted: Wed Oct 26, 2005 5:03 pm (написано за 1 минуту 6 секунд)
   Post subject: Как построить модель фотоальбома?
Reply with quote

Всем добрый день!

Хочу спросить совета у всезнающего All!

Задумал я сайтик на PHP слепить, да не просто сайтик, а как-бы фотоальбом.

Для фотоальбома есть куча (большущая!) фотографий, структурированных в дерево папок.

В дополнение к фукнции показа превьюшек и самого альбома хочу добавить следующие возможности:

- заголовок и описание к каждой фотографии
- разбивка по страницам
- поиск по описанию, заголовку
- комментарии к фотографиям

и вдобавок сохранить на сервере структуру папок. Просто действительно фоток очень много и структура годами :-) отработана.

так вот, уперся я в проектирование модели сайта.

Как хранить все эти данные и как администрить сайт?

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

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

(3)Третье - в базе не хранить поля раздел-подраздел, а всегда выполнять поиск по имени картинки в дереве папок... медленно будет. Во втором случае получается хоть и с кешем, но быстрее. Но зато перемещать картинки просто - переместив картинку из раздела в раздел она сама себя перемещает в новый раздел. И не надо актуализировать. Но при добавлении все равно надо.

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

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

Всем спасибо за ответы!

PS: Прошу не обращать внимания на терминологию, возможно необщепринятую. Писал все из головы, что придумал.
Back to top
View user's profile Send private message
Ksnk
Участник форума



Joined: 24 Jun 2005
Posts: 459
Карма: 49
   поощрить/наказать

Location: СПб

PostPosted: Wed Oct 26, 2005 7:25 pm (спустя 2 часа 21 минуту; написано за 3 минуты 42 секунды)
   Post subject:
Reply with quote

Не профессионал :), но как-то пытался на эту тему думать... вот imho
Где хранить служебную информацию - вопрос! Однако, если с базой данных все равно придется связываться - то, очевидно, что в базе. Делать один запрос или два-три, как правило, время одного порядка, да и поиск организовать несколько проще. Если необходимость базы еще обсуждается, а количество фотографий не "очень велико" - то можно и классы serialize'овать в файлах.

Альбом - базовая сущьность. Содержит "заголовок-описание" альбома и список фотографий с описанием по каждой. Адрес фотографии может быть и "абсолютным", так как перемещать собственно фотографии не придется (разве что удалять...), так что имя фотографии можно сделать ключевым полем. Одна и та-же фотография вполне может находиться в нескольких альбомах и содержать разные комментарии. Текстовый поиск ведется только по таблицам альбомов.

Тема - сущьность с описанием, содержащая список тем, либо список альбомов.

Фотографии лежат в отдельном месте, как правило, примерно в том-же порядке, в каком они появляются на рабочем компьютере - новый день - новая папка. Это для того, чтобы удобнее было "визуально" проверять - загрузил ли "этот день" уже или нет.
В том-же каталоге находится "неизменяемая информация по фотографиям". К примеру - Exif(теряется при конвертировании GD) если вдруг понадобиться, "базовые комментарии к фотографии", "Базовый раздел-тема альбома", еще чего-нибудь. На каждый каталог таким образом формируется альбом, с темой "список фотографий".

Создание альбома: копирование уже существующих записей из альбомов темы "список фотографий" во вновь создаваемый альбом.
Редактирование альбома: Разбить на 2 части по темам. (Дальше каждый альбом редактируется отдельно ). Объединить несколько альбомов. Удалить из альбома фотографию. Удалить пользовательские комментарии...
Редактирование "тематического дерева": Достаточно, видимо только переименовывать и удалять.

Собственно - генерация страницы галлереи - "раскручиваем" тему с нужным именем.

Пользовательнские комментарии привязываются к соответствующей строчке альбома.

Разбивка по страницам ведется на этапе формирования HTML.

Такой вот меморандум :) Может чего и понравится...
Back to top
View user's profile Send private message Send e-mail
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Wed Oct 26, 2005 8:57 pm (спустя 1 час 32 минуты; написано за 2 минуты 11 секунд)
   Post subject:
Reply with quote

Ksnk
Ой, чего-то много слов, толку не особо много... Извините, если обидел.
zetter wrote:
как-же все-таки лучше поступить, чтобы и структуру папок сохранить и жизнь не осложнять?
Создать базу с однозначным соответсвием между полным путём до папки и её названием, + продумать, чтобы сохранялась при этом вложенность (я думаю, это не представляет особых проблем).

После того, как такая структура создана, задача заполнения комментариями, всякой другой информацией является тривиальной.

P.S. Не верьте тем, кто говорит, что надо работать с файлами, это полный бред. База, база и ещё раз база
Back to top
View user's profile Send private message Send e-mail
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Wed Oct 26, 2005 9:34 pm (спустя 36 минут; написано за 9 минут 1 секунду)
   Post subject:
Reply with quote

1. минимальная информация по фото
ИД
ИД_раздела
ИД_альбома (несколько избыточно)
ИД_пользователя (если много пользователей)
"габариты" файла (ширина, высота, физический размер файла)
храните картинки в файловой системе (а в БД ссылки на них, предусмотрите preview к каждой картинке - в таком случае еще одна ссылка на превью)

2. картинки кидать легче в кучу. не будете иметь проблем с разросшейся файловой системой - данные хранятся централизовано

3. картинка может иметь произвольное имя, например, md5(date() . $user_id . $_FILES['name']). вы в БД можете хранить реальное имя (для статистики), путь оригиналу, путь к превьюшке

при перемещении картинки из раздела в раздел вы будете менять поле ИД_раздела, например
Code (SQL): скопировать код в буфер обмена
UPDATE images SET image_section_id = ? WHERE image_id = ?
4. см. 1 и 2
Back to top
View user's profile Send private message
zetter
Заглянувший



Joined: 26 Oct 2005
Posts: 13
Карма: 0
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 3:19 pm (спустя 17 часов 45 минут; написано за 12 минут 53 секунды)
   Post subject:
Reply with quote

Ksnk
Quote:
Где хранить служебную информацию - вопрос! Однако, если с базой данных все равно придется связываться - то, очевидно, что в базе. Делать один запрос или два-три, как правило, время одного порядка, да и поиск организовать несколько проще. Если необходимость базы еще обсуждается, а количество фотографий не "очень велико" - то можно и классы serialize'овать в файлах.
Я думаю, что вопрос наличия базы решаем в ее пользу. Слишком много положительных моментов :-)
Quote:
Альбом - базовая сущьность. Содержит "заголовок-описание" альбома и список фотографий с описанием по каждой. Адрес фотографии может быть и "абсолютным", так как перемещать собственно фотографии не придется (разве что удалять...), так что имя фотографии можно сделать ключевым полем. Одна и та-же фотография вполне может находиться в нескольких альбомах и содержать разные комментарии.
Выходит, что поля ".. , альбом, раздел, имя_файла, .." можно трансформировать в /альбом/раздел/имя_файла.jpg или используя транслитерацию для создания пути, чтобы не хранить соответствия каталогов названиям полей - /albom/razdel/imya_fajla.jpg
Красиво получается.
При добавлении получаем список файлов раздела и проверяем наличие полей ".. , альбом, раздел, имя_файла, .." соответствующих каждому файлу. Если в базе их нет - добавляем запись.
Quote:
В том-же каталоге находится "неизменяемая информация по фотографиям". К примеру - Exif(теряется при конвертировании GD) если вдруг понадобиться, "базовые комментарии к фотографии", "Базовый раздел-тема альбома", еще чего-нибудь.
А почему в файлах, а не в базе? Это чем получается выигрышнее?

Юpий Насрeтдинов
Quote:
Создать базу с однозначным соответсвием между полным путём до папки и её названием, + продумать, чтобы сохранялась при этом вложенность (я думаю, это не представляет особых проблем).
Вот вроде все получается, как я писал выше или подобным образом. Но если вдруг кто-то просто сотрет файл???? Я к чему веду: информация о пути и имени файла хранится в двух местах - собственно в имени и пути файла и в базе, причем они не связаны между собой. Если мы удаляем файл - запись в базе начинает указывать на пустоту? Вариант с поиском файла по имени тут бы помог.

Rumata
Quote:
храните картинки в файловой системе (а в БД ссылки на них, предусмотрите preview к каждой картинке - в таком случае еще одна ссылка на превью)

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

All

Что вообще первично - файл картинки или запись о нем в базе?
Back to top
View user's profile Send private message
Артeм Дивинcкий
Участник форума



Joined: 19 Jul 2005
Posts: 61
Карма: 6
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 4:37 pm (спустя 1 час 17 минут; написано за 51 секунду)
   Post subject:
Reply with quote

Rumata wrote:
md5(date() . $user_id . $_FILES['name']).
Это, пожалуй, лишнее. (-;
Rumata wrote:
информация по фото
ИД
Back to top
View user's profile Send private message Send e-mail
Колесов Максим
Заглянувший



Joined: 16 Jul 2005
Posts: 10
Карма: 0
   поощрить/наказать

Location: МосковЪ.

PostPosted: Thu Oct 27, 2005 4:49 pm (спустя 12 минут; написано за 3 минуты 41 секунду)
   Post subject:
Reply with quote

zetter
Quote:
 Но если вдруг кто-то просто сотрет файл???? Я к чему веду: информация о пути и имени файла хранится в двух местах - собственно в имени и пути файла и в базе, причем они не связаны между собой. Если мы удаляем файл - запись в базе начинает указывать на пустоту? Вариант с поиском файла по имени тут бы помог.
а не проше ли filesize() использовать?

Ибо простая верификация размера ИМХО гораздо быстрее поиска.

Варианты реализации:
= размер хранить в базе, если не совпадает - error
= размер сравнивать на лету, если файла нет - невозможно будет получить размер.

Last edited by Колесов Максим on Thu Oct 27, 2005 5:03 pm; edited 1 time in total
Back to top
View user's profile Send private message
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 4:55 pm (спустя 5 минут; написано за 2 минуты 8 секунд)
   Post subject:
Reply with quote

Артeм Дивинcкий wrote:
Это, пожалуй, лишнее
отчасти. при хранении файлов в куче необходима уникальность имени
zetter wrote:
может их в базу тогда запихать и не заморачиваться
почитайте в инете - на эту тему там много дискуссий
zetter wrote:
превьюхи лучше генерить на лету или хранить?
генерируйте при выгрузке файла на сервер и сохраняйте в другой файл.
Back to top
View user's profile Send private message
Колесов Максим
Заглянувший



Joined: 16 Jul 2005
Posts: 10
Карма: 0
   поощрить/наказать

Location: МосковЪ.

PostPosted: Thu Oct 27, 2005 5:02 pm (спустя 7 минут; написано за 1 минуту 38 секунд)
   Post subject:
Reply with quote

Rumata
Quote:
при хранении файлов в куче необходима уникальность имени
А переименовывать файлы при загрузке?

Опять-же, если нужно никто не мешает сохранять "родительские" имена файлов в БД.
Размер БД фактически не увеличится, а от папок отказ.
Back to top
View user's profile Send private message
Ksnk
Участник форума



Joined: 24 Jun 2005
Posts: 459
Карма: 49
   поощрить/наказать

Location: СПб

PostPosted: Thu Oct 27, 2005 5:22 pm (спустя 19 минут; написано за 1 минуту 35 секунд)
   Post subject:
Reply with quote

zetter wrote:
А почему в файлах, а не в базе? Это чем получается выигрышнее?
В производительности - ничем, если база есть. Это я свой вариант вспоминал, он был весь на файлах
Юpий Насрeтдинов wrote:
много слов, толку не особо много...
Да... сумбурно получлось :( Видимо, так и останусь непонятым :)
zetter wrote:
Скажите, а если картинки в куче, то может их в базу тогда запихать и не заморачиваться?
И еще, немножко в сторону от темы: превьюхи лучше генерить на лету или хранить?
Все зависит от объема хранимых картинок. Как иллюстрация - запрос к базе выдал 100 картинок. Результат сразу попадает в массив и, если каждая картинка более 1 метра - получаем расход памяти для выполнения скрипта +100 метров. Я обычно на сервере хранил картинки 800x600. Так они занимают около 30-50 кб и не сильно мешают жить. Итого - большие картинки - в файлах, маленькие - хоть в базе :)
Про превьюхи: Безопаснее и проще для хостера - в файлах, однако, опять-же зависит от объема картинки. Из метровых картинок превью создаются медленно, а превью для 800х600 - практически так-же как из файлов. Конечно, если собственно сервер не очень нагружен...
P.S. В поиск по дискуссиям на эту тему и сам обязательно схожу... ;)))
Back to top
View user's profile Send private message Send e-mail
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 6:22 pm (спустя 1 час 37 секунд; написано за 11 минут 9 секунд)
   Post subject:
Reply with quote

я плохо объясняю?
ваш скрипт
1. получает и проверяет файл на валидность
2. сохраняет в доступное место (например в %DOCUMENT_ROOT%/images)
3. создает превью (например в %DOCUMENT_ROOT%/thumnails)
4. заносит в базу
   а) номера раздела (куда запостили) и пользователя (кто запостил)
   б) путь к оригиналу
   в) путь к превью
   г) информацию о файле (mime, размеры)
Back to top
View user's profile Send private message
Rumata
Профессионал



Joined: 17 Aug 2003
Posts: 1850
Карма: 185
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 6:24 pm (спустя 1 минуту 59 секунд; написано за 24 секунды)
   Post subject:
Reply with quote

при желании можете
   д) сохранить оригинальное название файла
Back to top
View user's profile Send private message
Артeм Дивинcкий
Участник форума



Joined: 19 Jul 2005
Posts: 61
Карма: 6
   поощрить/наказать


PostPosted: Thu Oct 27, 2005 9:16 pm (спустя 2 часа 52 минуты; написано за 5 минут 40 секунд)
   Post subject:
Reply with quote

Rumata Лишнее - вычисление md5(date() . $user_id . $_FILES['name']), а не уникальность. Я имел ввиду, что уникальность имени можно обеспечить используя ИД фотографии. Для этого я и привел вторую цитату из Вашего сообщения.
Предполагается поле ИД в таблице auto_increment (ну, или не авто... (-: в любом случае целое, а не char(32)).
Back to top
View user's profile Send private message Send e-mail
zetter
Заглянувший



Joined: 26 Oct 2005
Posts: 13
Карма: 0
   поощрить/наказать


PostPosted: Fri Oct 28, 2005 4:51 pm (спустя 19 часов 34 минуты; написано за 2 минуты 22 секунды)
   Post subject:
Reply with quote

Вот после многочисленных раздумий остановился на такой структуре базы.

fa_picture
field type
id_pic id, primary key, auto_increment
name_picture varchar 40
group_picture varchar 20
subgroup_picture varchar 20
short_text varchar 40
long_text text 16
date timestamp
width int 16
height int 16
views int 32
rating int 8
comments_counter int 16
    
fa_comments
field type
id_comment id, primary key, auto_increment
picture fa_picture.id_pic
user fa_users.id_user
date timestamp
comment text 16
    
fa_users
field type
id_user id, primary key, auto_increment
name varchar 10
email varchar 40
date_reg timestamp
messages_num int 16
Back to top
View user's profile Send private message
Юрий Насретдинов
Модератор



Joined: 13 Mar 2003
Posts: 8642
Карма: 198
   поощрить/наказать

Location: 007 495

PostPosted: Fri Oct 28, 2005 7:45 pm (спустя 2 часа 53 минуты; написано за 27 секунд)
   Post subject:
Reply with quote

zetter
Лучше расскажите, как Вы собираетесь эту самую базу заполнять и следить за ней
Back to top
View user's profile Send private message Send e-mail
Антон Макаренко
Участник форума



Joined: 05 Feb 2004
Posts: 374
Карма: 31
   поощрить/наказать

Location: Киев

PostPosted: Thu Nov 17, 2005 11:59 am (спустя 19 дней 16 часов 13 минут; написано за 17 минут 51 секунду)
   Post subject:
Reply with quote

Quote:
... в текстовых или каких-то еще файлах.
Я бы попробовал один XML-файл на весь фотоальбом.

Преимущества XML в контексте хранилища структуры данных для приложения "фотоальбома":
1) Не требуется БД. Значит меньше возни с коннектами, аккаунтами, запросами и т.п.
2) Возможность задать любую структуру данных. Любую.
3) При грамотной реализации можно даже отказаться от использования PHP для просмотра альбома (кажется, начинает попахивать оффтопиком). Вместо этого -- тупо трансформировать этот XML-файл с помощью XSLT. В таком случае PHP-приложение будем использовать только для управления содержимым XML-файла, для upload`а и ресайза картинок.

Недостатки данного подхода:
1) Отсутствие в PHP внятных и простых средств для работы с XML. В основном -- низкоуровневые расширения (SAX, DOMXML). Иными словами -- сложность алгоритмов работы с деревом XML.
2) Необходимо придумать понятную, универсальную, простую и расширяемую структуру данных. Это несложная (благодаря универсальности XML), но трудная задача, поскольку требуется написать корректную схему DTD или XSD.

В принципе, недостатки решаются. Лично у меня есть решение для первого. Со вторым вопросом -- могу помочь разве что со схемой DTD.

Уважаемые участники форума, как вы думаете, имеет ли эта идея место под солнцем?
Back to top
View user's profile Send private message Send e-mail
zetter
Заглянувший



Joined: 26 Oct 2005
Posts: 13
Карма: 0
   поощрить/наказать


PostPosted: Thu Nov 17, 2005 2:10 pm (спустя 2 часа 10 минут; написано за 42 секунды)
   Post subject:
Reply with quote

Простите за долгое молчание...
Вот получился еще один вариант, наверное более правильный на мой взгляд:
(5) по сути - модифицированный метод (1)
Добавление новых картинок производится с помощью папки Inbox. Это специальная папка для новых фотографий. Скрипт актуализации теперь просто скрипт добавления. При наличии файлов в Inbox выдает форму ввода данных и согласно ей раскидывает файлы по папкам. Этим убиваем двух зайцев - проблема добавления большой кучи файлов единовркменно и получаем возможность работы с FTP.
Общее администрирование производится скриптом администрирования. Его задача - изменение информации в БД, соответствующая перетасовка файлов, удаление и т.д.
Исходная информация о местоположении файлов содержится в БД. Доступа к файловой структуре понятное дело напрямую нет.
Главный скрипт - это скрипт просмотра. Он-же обеспечивает просмотр и добавление комментариев, сбор статистики и т.д.
Back to top
View user's profile Send private message
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Thu Nov 17, 2005 2:33 pm (спустя 23 минуты; написано за 1 минуту 41 секунду)
   Post subject:
Reply with quote

Насчёт
zetter wrote:
Доступа к файловой структуре понятное дело напрямую нет.
подумайте отдельно.
Картинки могут быть больших размеров. Недавно я столкнулся с проблемой, что PHP даже при лимите в 128Мб не может отдать 4Мб файл.
Back to top
View user's profile Send private message
Advanced Guest
Guest





Карма: 388
   поощрить/наказать


PostPosted: Sun Nov 20, 2005 3:23 am (спустя 2 дня 12 часов 49 минут; написано за 51 секунду)
   Post subject:
Reply with quote

WingedFox, а при каких условиях проявилась проблема? vbulletin у меня на хостинге свободно позволяет загружать и отдаёт файлы размером до 28 метров, больше просто не было.
Back to top
WingedFox
Профессионал



Joined: 29 Apr 2003
Posts: 4064
Карма: 268
   поощрить/наказать

Location: Питер

PostPosted: Sun Nov 20, 2005 4:19 am (спустя 55 минут; написано за 1 минуту 1 секунду)
   Post subject:
Reply with quote

Advanced Guest
Надо смотреть, как в vbulletin сделана отдача файлов.
Проблема возникла с Horde/IMP (вебмэйл-клиент). Там просто делается readfile();
Back to top
View user's profile Send private message
Advanced Guest
Guest





Карма: 388
   поощрить/наказать


PostPosted: Sun Nov 20, 2005 1:46 pm (спустя 9 часов 27 минут; написано за 41 секунду)
   Post subject:
Reply with quote

WingedFox через file_get_contents или fread в память и потом echo на экран. Вроде даже тяжелее чем можно было бы сделать:\
Back to top
Display posts from previous:   
Post new topic   Reply to topic All times are GMT + 3 Hours
Page 1 of 1    Email to a Friend.
You cannot post new topics in this forum. You cannot reply to topics in this forum. You cannot edit your posts in this forum. You cannot delete your posts in this forum. You cannot vote in polls in this forum. You cannot attach files in this forum. You can download files in this forum.
XML