Давайте Вы подробно разжуёте что вы имеете в виду, а то есть непонимание.
|
Цитата:
|
|
изображений для планируемой раздачи на трекере
|
Раздачей чего на трекере? Картинок? Картинки отдаёт сервер по сети при запросе в любом случае. Не важно что у Вас будет стоять для отдачи статики nginx/apache, но отдавать будет сервер, когда браузер будет делать запрос на получение картинки.
|
Цитата:
|
|
Поиск был нужен для удобства пользования, поскольку в их именах будут содержаться до восьми категорий
|
В имени картинки Вы собираетесь хранить метаданные о картинке? Ну это верный способ выстрелить себе в ногу.
Я вам предлагаю конкретную реализацию.
У вас в БД в таблице pictures четко сказано у какой картинки какой url, при этом на каждую картинку у вас может быть любое кол-во метаинформации, которая содержится в таблице picture_metadata. Соответственно поиск вы осуществляете по метаинформации, и возвращаете на клиент(в браузер) урлы картинок, которые соответствуют параметрам поиска, после чего уже рисуете (возвращенные строчки отдаете шаблонизатору). Если вы используете фреймворк на клиенте, то у вас скорее всего результат апи будет храниться в "модели" и настроить пагинацию будет просто(каждый фреймворк имеет свою реализацию пагинации).
Теперь по поводу того, что во вложение, во-первых сомневаюсь, что кто-то это писал руками (похоже на работу какого-то генератора статики). Во-вторых поиск, как вы можете сами видеть, авторы в js файл(dhtml_search.js) определяют массив длинной 33к строчки и файл js весит 8мб, а если картинок будет больше? Алгоритм поиска также простой, проходятся по массиву и проверяют вхождение строчки поиска в каждый элемент массива, 100мс уходит на такой проход на моем пк. Скажу так, это медленно. В общем это не рабочее решение в перспективе.
Мне думается что для решения вашей проблемы вам необходимо больше фундаментальных знаний касательно разработки web приложений.