о том как хранить картинки...

Статус
В этой теме нельзя размещать новые ответы.

zyablik

Новичок
о том как хранить картинки...

преамбула:
возможно гдето буду неточен в формулировках и терминологии (особенно что касается объект\не объект вчасности и ооп вообще)


вопрос: как хранить картинки(ссылки на картинки) в своей цмс

вводная информация:
есть своя развивающаяся цмс.
архитектура цмс:
1.базовая таблица
для хранения ссылок на объекты и неких общих характеристик, таких как,
- ид
- название
- путь от корня сайта
- скрипт отображения
- тип объекта
- папка (тру\фолс)
- статус (отображать тру.фолс)

2. таблица имен объектов items
- имя
- дефолтный скрипт отображения
- дефолтное значение папка(тру\фолс)

3. таблица параметров объектов
- имя объекта
- имя поля
- тип поля

это основа цмски

после инсталяции системы имеем 3 таблицы и скрипты цмски
идеология работы на примере новостей
создаем объект новость
при создании объекта у разработчика спрашиваются такие вещи как
- имя объекта
- скрипт отображения
- папка?
пример (obj=news, title= Новость, script=news,isFolder=false)

в системе создается таблица news имеющая дефотные поля
id-autoincrement
parent
order
ElementName
path

в таблицу items добавляется запись
item=news,name=Новость,script=news,isfolder=false

далее разработчик у объекта новость добавляет параметры
- анонс
- полный текст
- картинка
итп
при добавлении параметра объекта
в таблицу параметров добавляется значение и изменяется таблица новости добавлением поля
тоесть в таблице параметров хранится список дополнительных полей для каждой таблицы новых обхектов

далее администратор сайта
добавляет новость.
заполняет поля, сабмитит, новость появляется
при сабмите
в главную таблицу добавляется новая запись
- генерится ид
- геренится путь до новости
- название новости (дублирующее поле)
- order дефолтный
- скрипт берется из таблицы объектов

в таблицу новостей добавляется вся инфа о новости
анонс
полный текст
путь до картинки

в шаблоне отображения новостей делаю запрос по двум таблицам
из главной и таблицы новостей
в итоге получаю всю информацию об объекте
пример запроса
SELECT * FROM news,main WHERE news.ElementID = main.ElementID AND main.isNode = '0' AND main.is_virtual = '2' ORDER BY main.ElementOrder ASC, main.ElementID ASC


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


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

минусы решений
1. в админке писать обработчик который в одно поле будет запихивать всю инфу и в шаблонах для отображения вместо
<img src=$news['pic']>
придется писать обработчик который будет доставать нужное значение
2. дополнительный запрос к базе для отображения каждой картинки.

что думаете?
 

alpine

Новичок
zyablik
Ой, слишком много букв ... :D

-~{}~ 07.03.07 22:48:

PS MySQL то тут при чем? Хранить параметры изображения или не хранить в БД? Вот в чем вопрос? ;)
 

zyablik

Новичок
вообщем то да,
и если хранит, то как?
спецтаблицей, или всякучаводномполе
 

Фанат

oncle terrible
Команда форума
Фанат скажет, что бояться того, что иногда идет обращение к диску и вычисление размеров изобажения, это все равно что бояться лишний раз открыть дверь холодильника на том основании, что от частого открывания она отвалится.

блин, прочитать несколько байт из файла - это блин одна из самых простых операций.

сколько раз уже здесь говорили, не сто и не двести - оптимизировать надо ТО ЧТО ТОРМОЗИТ, а не то, что из пальца высосали.
 

zyablik

Новичок
фанат,
оптимизировать нечего, ибо еще не выбран способ реализации во первых,
во вторых
иногда - применимо к общему кол-ву реализуемых проектов в целом.
тоесть в 1 из 10 проектов такой функционал нужен..
а вот в самом проекте уже применимость может быть часто использумой
ну например отображение страницы превьюшек в кол-ве 100-300 штук - что лучше, брать инфу о размере картинки функцией гетимаейджсайз, или из базы?
читайте внимательней уважаемый фанат
 

phprus

Moderator
Команда форума
zyablik
ну например отображение страницы превьюшек в кол-ве 100-300 штук - что лучше, брать инфу о размере картинки функцией гетимаейджсайз, или из базы?
Если на странице по 100-300 превьюшек, то я бы стал брать информацию о размере из базы. Но вообщето 100-300 превьюшек - это маразм ибо такая страница будет очень тяжелой и пользователь не всегда будет дожидаться ее полной загрузки. ИМХО оптимальное кол-во - 25-30 на страницу.
 

Фанат

oncle terrible
Команда форума
во-первых, 100-300 - это маразм.
во-вторых, запусти функцию гетимаейджсайз 300 раз, замерь время, и перестань парить людям мозги.
в-третьих, ты так и не понял что нужно оптимизировать, а что не нужно.
в-четвёртых, не надо мне указывать, что читать внимательнее. ОСОБЕННО после вываливания здоровенного текста рассуждений, высосаных из пальца и после того, как в МОЁМ сообщении не было понято ни одной буквы.

В общем, топик закрываю. Не по какой-то провинности, а просто из-за бессмысленности.
Очередная "проблема", которая высосана из пальца.

-~{}~ 08.03.07 10:13:

Вообще, меня сильно занимает вопрос - а головой ли эти люди думают?
при чем здесь вся эта здоровенная преамбула на 5 килобайт про структуру базы?

И всё ради чего? Ради двух совершенно гениальных вопросов!
минусы решений
1. в админке писать обработчик который в одно поле будет запихивать всю инфу и в шаблонах для отображения вместо
<img src=$news['pic']>
придется писать обработчик который будет доставать нужное значение
ПИПЕЦ. Смерь программисту. Придётся! Писать! Обработчик!!!
Вы только вдумайтесь! Кабала лет на 30 - не меньше! столь большой ужас вызывает это мерприятие, что пишется здоровенный пост в форум (по объёму - сравнимый с объёмом "обработчика") и тратится время на обсуждение, сравнимое с временем на написание обработчика.
2. дополнительный запрос к базе для отображения каждой картинки.
Удивительно. Второй за последнее время встречаю такое утверждение. То есть, ИМЯ картинки откуда-то берётся само, а за размерами надо лезть отдельно!

Мля.
чем больше я читаю этот топик, тем больше зреет убеждение, что общаюсь я либо с троллем, либо с идиотом.
сначала оно пишет (читаем, как нас просили, ВНИМАТЕЛЬНО):
иногда возникает необходимость получать(отображать на сайте) дополнительную информацию о картинках (файлах)
и вдруг выясняется, что это "иногда показать картинку" выливается в 100-300 на страницу.

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

-~{}~ 08.03.07 10:27:

Вообще, наверное, мы здесь видим типичное поведение человека, который взялся за задачу, которая ему явно не по зубам.
При совершенно заумной структуре приложения - АБОСЛЮТНО универсальной и абстрактной (чего до сих пор не удавалось никогда и никому), сами вопросы - уровня детского сада. Своими вопросами он выдаёт РЕАЛЬНЫЙ уровень своего мышления.

Лишний запрос к базе данных vs getimagesize - это единственная проблема всей разработки. Других нету.

А дальше уже от умственного перенапряжения голова вразнос пошла, и начались совсем неадекватные реплики. Кажется, так.
 

zyablik

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

При совершенно заумной структуре приложения - АБОСЛЮТНО универсальной и абстрактной (чего до сих пор не удавалось никогда и никому)
далее.


Удивительно. Второй за последнее время встречаю такое утверждение. То есть, ИМЯ картинки откуда-то берётся само, а за размерами надо лезть отдельно!
вследствии невнимательности и такие тупые высказывания
читай выше

вообщем дальшейшую дискуссию с фанатом продолжать не имеет смысла.
интересует мнение остальных форумчан

-~{}~ 08.03.07 12:09:

Автор оригинала: phprus
zyablik

Если на странице по 100-300 превьюшек, то я бы стал брать информацию о размере из базы. Но вообщето 100-300 превьюшек - это маразм ибо такая страница будет очень тяжелой и пользователь не всегда будет дожидаться ее полной загрузки. ИМХО оптимальное кол-во - 25-30 на страницу.
спасибо, я тоже склоняюсь к этому мнению
ибо если рассматривать простые операции
то
1. чтение скрипта - дисковая операция
2. запрос к базе селект -это дисковая операция
3. в памяти уже хранится вся информация о новости и вчасности о картинке
поэтому чтение данных с диска для определения размеров картинки отсутствует. тоесть упрощаем как минимум на одну итерацию

-~{}~ 08.03.07 12:12:

и вдруг выясняется, что это "иногда показать картинку" выливается в 100-300 на страницу.
разжевывать еще раз не хочется.. другие все прекрасно поняли....
 

Фанат

oncle terrible
Команда форума
дасвидание
троллей просят пройти для кормёжки в зоопарк.
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху