Фото галерея

Добрый день!
Надо сделать фото галерею.
Галерея должна содержать: название фото, свойства (опционально), alt для тэга <img> и ТЭГИ.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ЗАЧЁРКИВАЕМ ВСЁ!!!!

Мой вариант структуры таблицы БД:
1) table - gal
id
name
... (createtime, onoff, author, etc...)

2) table - gal_pics
id
gal_id
name
path (тут ВОПРОС: лучше сделать три поля с ссылками на тумбнейл, большой, оригинальный размеры фото, или же достаточно сделать путь к папке, а там 3 папки: orig, thumb, full?? по ид создавать паку не хочеться, хотя??? почему бы и нет???)
size, h_size, v_size, type (свойства изображения. ВОПРОС: лучше при загрузки добавлять свойства, или на лету брать инфу из файла-изображения?)
tag (сдесь вообще не знаю как лучше? писать через разделитель (запятая+пробел или как-то иначе?)
.... (updatetime, author, onoff, etc....)

Соответственно 2 вопроса по структкре и вопрос по тэгам:
Как тэги записывать ЛУЧШЕ в БД и потом работать с ними???

Ниразу не работал с ТЭГАМИ....


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ЗАЧЁРКИВАЕМ ВСЁ!!!!

Коллективным умом решили делать в 4 таблицы:

1) g_name:
id
name
path
...

2) g_pic:
id
g_nid (на таблицу g_name)
name
alt
...

3) g_pic_taging
id
g_pid (на таблицу g_pic)
g_tag

4) g_tag
id
tag
==========

т.е.: 1) создаётся галерея (g_name),
генерируется случайная папка (path).
2) Заполяются ей (галереи UP) картинки (g_pic),
приписываются к каждой тэги из готовых (g_tag) или из новых (+g_tag)
3) ....

ВОПРОС: Всё равно криво будет с добавлением тэгов! это отдельная таблица, регулярой я выну тэги из инпут-пост-формы, по одному занесу в таблицу g_tag, в таблицу (g_pic_taging) пропишу id'шники, но если вдруг, что ручками править, это будет не айс.
Как же галереи делаются?

З.Ы. Сделаю, унифицирую, выложу.... Спасибо

(Отредактировано автором: 23 Июня, 2010 - 03:13:45)

Бррр.. как-то все сложно. Зачем привязывать теги по id? Чтобы редактировать существующие теги и они менялись в картинках? Но зачем???
Я бы сделал проще. 3 таблицы:
1. галереи
2. картинки (с полем "тэги")
3. тэги (таблица с тегами нужна, чтобы в дальнейшем выбирать из существующих, иначе и она нафиг...)
При добавлении новой картинки с тэгами, бьем их по запятой (explode(',', $_POST['tags']));
if(3. тэги) заносим в таблицу с тэгами;
Приводим тэги картинки к нужному виду с помощью implode() и заносим получившуюся строку в поле "тэги".
Потом, для поиска картинок по тэгам используем LIKE в mySQL запрсе.

У меня подобные вещи реализованы следующим образом.
Сохранение:

Uchkuma Всё супер, но вот LIKE в мускуле очень затратная конструкция...
Поэтоиу и думая создать связующую таблицу, а не поле, которое потом експлодить (,+пробел)

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

Количество изображений в базе сравнимо с контактом? :)

нет,
просто не хочу быдлокодить.
Лёгкий и универсальный вариант.

Самыми затратными являюется не конструкции выолняемые внутри одного SQL-запроса - а те при которых происходит определенный SQL-запрос который передается в PHP-скрипт для дальшейшей обработки - и на основе которого строится очередной следущий SQL-запрос В таком случае недостаток заключается в излишней передаче данных между сервером приложений и БД

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

всё, пишу в 2 таблицы (имя галереи и собственно картинки), и выбирать буду LIKE .

Спасибо. Если будет тормозить, переделаю.

А стоит в базу заносить размеры и вес картинки, или лучше налету getimagesize'ом????

(Отредактировано автором: 23 Июня, 2010 - 14:22:00)

Вы главное формируйте условия в SQL-запросе таким образом чтобы в начале оператора короткого замыкания использоваться самый быстрый оператор сравнения - то есть сначала вы проверяете какой-то из индексированных ключей и если он не прошел то LIKE уже проверяться не будет

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

JustUserR важное замечание, спасибо.

Пожалуйста! Такой подход часто используется при решении ресурсоемких задач - к примеру если определенный поиск в любом случае будет составлять определенную сложность - то вариантом решения вялется сокращение зоны поиска В общем случае это похоже на редукцию NP-полный задач

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/