Здравствуйте!

Пишу скрипт для отображения новостей на странице сайта.
Всё находится в одной таблице в MySql.
У новостей есть фотографии, одна из них показывается рядом с новостью, чтобы посмотреть остальные нужно щелкнуть на основное фото, подгрузится скрипт JS с галереей.
Фотографии новостей ищу в папках с новостями php скриптом.

Вопрос: как лучше организовать хранение описаний этих фотографий?
Бывает что у каждой фотографии в новости разное описание...


@темы: База данных, PHP, Интернет, MS SQL

Комментарии
27.04.2012 в 16:50

могутні вовняні лаписька
LuNa82, у нас это все цеплятеся в отдельный gallery.xml-файл. структура такая:
\картинки сайта\папка с id новости\gallery.xml и картинки к новости
27.04.2012 в 16:54

Руди Мюллер, т.е. описания хранятся не в базе, а в отдельном файле?
А можете дать ссылку хорошую про xml?
27.04.2012 в 17:09

After silence that which comes nearest to expressing the inexpressible is music.
LuNa82, Как вариант завести доп таблицу newsImages с полям FileName, newsId, description И к каждой новости забирать эти фоты.
27.04.2012 в 17:49

могутні вовняні лаписька
LuNa82, возможно, но точно не скажу. возможно, они там и дублируются, возможно, хранятся вне базы. даже не знаю, где подсказать, сам не читал и не программировал.
27.04.2012 в 20:06

alhames.ru
Всё находится в одной таблице в MySql.
Добавляете дополнительное поле в табличку, скажем "photo", и туда сохраняете сериализованный массив вида:
- путь к файлу
- название картинки

Сам я не люблю хранить сериализованные данные в базе и всегда создаю отдельную табличку для фото.
27.04.2012 в 21:32

И тесно облакам.
Сделайте табличку с полями: id новости, имя файла фотографии, описание.
27.04.2012 в 22:28

I wait Caturday. I wait Catnarok.
Возможно меня сейчас закидают какахами, но возможен такой способ: сделать еще одно поле в таблицу новостей, где просто в виде json массива будут храниться адреса фотографий. Удобно обрабатывать js-скриптом, да и в php части трудностей не возникнет.
27.04.2012 в 22:30

I wait Caturday. I wait Catnarok.
alhames, вы видимо оптимизацией никогда не занимались. Вторая таблица - это всегда дополнительный join. А эта операция очень грузит процессор и ОЗУ. Если есть возможность, ее лучше избегать.
27.04.2012 в 22:55

alhames.ru
ДихлофосЪ, я предложил сериализованный массив - по сути тоже самое что и JSON, если данные обрабатываются не javascriptом.
JOIN я не делаю - в данном случае выборка фото происходит вторым запросом. Выборка 10-20 фотографий на странице, где в сумме не более 10-20 запросов не так уж критична. Зато намного проще и нагляднее управлять данными.
27.04.2012 в 22:57

И тесно облакам.
При наличии нормальных индексов JOIN — совсем не дорогая операция. Хранить сериализованный массив в таблице плохо и ненужно.
28.04.2012 в 01:21

After silence that which comes nearest to expressing the inexpressible is music.
При наличии нормальных индексов JOIN — совсем не дорогая операция. Хранить сериализованный массив в таблице плохо и ненужно. +1

Если есть возможность, ее лучше избегать. В таком случае к черту реляционные базы и айда на nosql. И да, я посмотрю сколько у вас памяти сожрет когда вы попытаетесь найти картинку по её описанию.
29.04.2012 в 14:55

Спасибо большое всем!

Заведу доп. таблицу.