Неиспользуемые файлы

[MadGreen]

Неиспользуемые файлы

Для облегчения управления сайтом я давно написал скрипт который проверяет наличие неиспользуемых файлов изображений на сервере: весь текст сайта хранится в MySQL и зная список имен файлов можно в лоб проверить какие из них не входят в теги сайта - на основании этого можно вывести пользователю список ненужных/старых файлов.
Однако недавно столкнулся с проблемой: кол-во файлов превысило 2000 и началась жуткая тормозня.
Может кто сталкивался с проблемой и видит другое решение нежели лобовой перебор всей БД?

 

[ksnk]

К примеру, можно выводить изображения через скрипт, в котором отмечать в базе (или еще где) время последнего доступа. Далее - запрос по базе - кого там последний раз выводили...
Можно в добавок, попробовать периодически запускать какой-нибудь поисковый робот, который индексирует сайт. и проиндексирует и "методом научного тыка" определит список доступных картинок.

Не ясно что делать с картинками, имена которых формируются на JS...

 

[Kelkos]

Если уж алгоритм такой, то придётся либо кроном делать, либо частями.
Вопрос: откуда берутся лишнии картинки? И может они там совсем не лишнии?

 

[MadGreen]

Лишние они... юзер ведь не думаю аплоадит все что можно... потом решил сменить картинку а про старую забыл... или слил не то что нужно....

-~{}~ 09.07.05 19:27:

а по времени доступа... ну а что если на странице кто-то бывает раз в год... (понимаю конечно что глупость), но нужна ведь универсальность и точность

 

[kruglov]

ну так только те картинки, у которых последнее время доступа / проверки меньше года / месяца / недели и проверяем.

 

[MadGreen]

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

 

[Фанат]

есть.
найти место, в котором происходит жуткая тормозня, и оптимизировать его

 

[kruglov]

Надеюсь, проверка делается не таким образом
foreach(картинки as $картинка){
просматриваем всю базу в поисках этой $картинка
}

 

[MadGreen]

нет конечно, просматриваются только те поля где физически может быть тег картинки
и тормозня это условное название, на проверку 2000 файлов уходит около двух минут...
хотелось просто узнать возможные варианты

 

[kruglov]

MadGreen
Значит ли это, что для 2000 картинок мы просматриваем каждое из полей, где "может быть тег картинки" 2000 раз?

 

[Tor]

на проверку 2000 файлов уходит около двух минут

если проверять раз в неделю, то расходы совсем не большие

 

[MadGreen]

согласен, но 2000 файлов это старт для коммерческого сервера... я с ужасом думаю что будет когда там к номиналу подойдет... тысяч эдак под 50

MadGreen
Значит ли это, что для 2000 картинок мы просматриваем каждое из полей, где "может быть тег картинки" 2000 раз?

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

 

[kruglov]

MadGreen
Если до первого совпадения, то, в среднем, при равномерном распределении картинок в базе, получится просмотр половины базы. Т. е. оптимизма не вызывает. Вызывает надобность в оптимизации. Поскольку обычно картинки умирают редко, то проверка 10 (20, 50, 1%) самых давно не проверявшихся картинок каждый день / 3 часа / час - это хорошо.

 

[MadGreen]

согласен - тем самым родился третий вариант: автопроверка без учета пользователя (только в этом случае будет работать % самых давно не проверявшихся)

но задумка была такая: дать возможность пользователю просканировать все файлы на предмет использования.

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

 

[encyclop]

Я неоднократно сталкивался в такой проблемой и нашел кардинальное, правда, стоившее немало времени решение.

Написал класс для объекта типа file
- номер
- название
- путь
- имя файла
- комментарий
- комментарий для alt или title
- размер (сколько весит)
- медиатип
- сабтип
- id владельца
- дата и время последнего изменения

От него наследует объект типа image
С дополнительными свойствами
- длина
- ширина
(по-моему, все, сейчас не буду заглядывать)

Разумеется, в отдельных классах "чистый" PHP, в дочерних - работа с базой и с файловой системой + встроенная возможность проверки на соответствие медиатипу, размер, длину и ширину (для объектов типа image) как по диапазону, так и при помощи операторов сравнения...

Много на это ушло времени, но зато вещь расширяемая и универсальная.

Разумеется, при таком подходе не стоит проблема удаления "лишних файлов": вместе с объектом, удаляется и его файл в файловой системе.
В случае чего - обработка ошибок на PEAR.
+ Возможность прокомментировать объект, что часто бывает нужно при фотогалерее, всяких схемах...
+ Возможность написать дочерние классы для объектов другого типа со своими "фенечками"

 

[MadGreen]

солидно

два вопроса:
1. а если у одного файла два три или больше владельцев? при удалении одного объекта удаляется файл принадлежащий другим или вводится доп. проверка?

2. или для каждого объекта image свой file?

 

[encyclop]

Автор оригинала: MadGreen
солидно

согласен...

Автор оригинала: MadGreen
1. а если у одного файла два три или больше владельцев? при удалении одного объекта удаляется файл принадлежащий другим или вводится доп. проверка?

У меня владелец файла - тот, кто создал, залил файл. Это всегда кто-то один.

Что же касается возможностей оперировать с файлами других лиц, то, конечно, же, можно включить эту возможность в объект: этакий массив массивов владельцев, где верхний уровень id владельца, а нижний - тип права, которым он обладает (один может только create, другой - create, update, delete, третий - view), и на уровне объекта проверять, имеет ли этот юзер право делать то, что он собирается, но...

По-моему, слишком неудобно. И вот почему... Как показывает практика, при разработке проекта привилегий становится все больше, существующие меняются, детализируются, просто задалбывало бы все время залезать в объект и менять там все, связанное с привилегиями...

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

С системой распределения прав может быть столько интересной и забавной "свистопляски", что это уже выходит за рамки заданной темы.

Вообще, очень ресурсоемко давать "множественные" права на уровне объектов. Как правило, это нужно только админам, и вышеприведенный вариант вполне работает.

Автор оригинала: MadGreen
2. или для каждого объекта image свой file?

не очень понял...

объект типа image - тот же файл, но с дополнительными свойствами (длина и ширина).

 

[MadGreen]

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

при удалении записи (или редактировании) удаляется только "объект типа image" или физически файл?

 

[encyclop]

Автор оригинала: MadGreen
я имел ввиду несколько другое: предположим файл используется в нескольких различных местах - в двух разных таблицах БД или в просто в разных полях таблицы.

при удалении записи (или редактировании) удаляется только "объект типа image" или физически файл?

Н-да...

Объект типа image, как, впрочем, и объект типа file - это запись в БД в таблице класса image или file + собственно файл.

При "заливке" файла автоматически создается запись в БД + файл размещается по к-л пути в файловой системе (информация о пути есть в записи)...

При удалении - удаляются как запись, так разумеется, и файл.

Обновлять можно как произвольную инфу о файле, так и сам файл: одновременно или отдельно.

Что же касается использования файла в других объектах, то там располагается ссылка на объект типа файл, его id в таблице. При удалении файла целесообразно удалять только эту ссылку, а не сам объект.

Что же касаеся проверки взаимосвязей объекта типа image с другими, то делать это лучше да и вообще целесообразно только при помощи сценария.