Работа с базой на 30 тысяч строк

[Rasy]

hdma, проблема может быть только в том что ты выдумал реализацию, а на деле никто так не делает. Например, я порекомендовал создать много таблиц, а это лишние потуги, проще все в одной держать. Пересмотри свои идеи, возможно тебе подойдет самая обычная галерея для вордпресса, или другой популярной цмс и делов то.

[laimas]

Нужен пример кода, который будет искать по множеству подгружаемых строк с несколькими параметрами (как по ссылкам).

Это не есть задача, это нечто абстрактное, а что конкретно нужно, не понять. Если поиск по базе, то создайте ее сначала, опишите параметры по которым нужно производить выборку. Если проблемы с этим, значит вопрос не в этот раздел. Если с этим все Ок, ставьте задачу, как организовать выборку по А-Х (а тут вопросов может возникать не один), с определенным выводом на странице.

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

[laimas]

Rasy,
никакого сарказма, так уж получилось, что это слово можно считать патентом Жириновского.

[EmperioAf]

Если правильно понял задачу, то решается она приблизительно следующим способом.

Делаем апи на любом серверном языке, скажем nodejs используя express для более удобного написания кода.

const app = express();

Делаем метод для выгрузки данных о картинках по запросу с параметром текста.

app.get(/search/:text, callback);

Берем СУБД, желательно реляционную. Скажем postgresql.
В нашей БД создаем следующие таблицы:
pictures(id serial, url text) unique_key(id)
picture_metadata(picture_id integer, metadata_name text, metadata_value text) foreign_key(picture_id, pictures.id)
Если мы построим индексы на picture_metadata.metadata_value и pictures.id, то на таблице pictures в 30к строк и скажем по 3-4 метаданных на каждую картинку, наш запрос отработает за пару миллисекунд, если не быстрее.

В нашем API берем библиотеку для работы с postgresql, и делаем запрос к нашей БД вида:
SELECT * FROM pictures p
JOIN picture_metadata pm ON p.id = pm.picture_id
WHERE pm.metadata_value like ???
Где ??? - параметр который пришел в api.
Полученные данные возвращаем из API на клиент в браузер.

В браузере код соответственно выглядит примерно так:

var apiUrl = "http://localhost/search/";
searchDiv.addEventListener('click', function() {
  var value = input.value;
  $.get(apiUrl + value, data => {
    drawPictures(data);
  })
})

Более правильного решения поставленной задачи я не вижу.
Можно конечно и без БД и апи.
Просто запихнуть эту плоскую структуру в js массивы, но тогда вас ждут проблемы. Во-первых будет медленно грузиться, т.к. помимо логики работы с данными в вашем файле будут все данные возвращаться при каждом запросе к серверу. Во-вторых сомневаюсь, что вы сможете написать столь же эффективные алгоритмы выборки данных из плоских структур чем это уже сделано в реляционных БД.

[hdma]

EmperioAf, спасибо за расклады! Вы упоминаете сервер, а поэтому хочется уточнить: это будет обособленно работать с 30—40 тысячами изображений для планируемой раздачи на трекере? Поиск был нужен для удобства пользования, поскольку в их именах будут содержаться до восьми категорий.

Пока имею вариант из вложения к посту, который приспособил из файла "Справки Parallels" )) — по 30 тысячам строк ищет практически моментально, но в отличие от примеров из предыдущих ссылок — здесь только одна общая поисковая строка и результаты также не ограничены пагинацией. Насколько представляю, в идеале было бы с возможностью выбора из категорий — как было выше по ссылке, но с открытием результатов в новом окне с пагинацией.

[EmperioAf]

Давайте Вы подробно разжуёте что вы имеете в виду, а то есть непонимание.

изображений для планируемой раздачи на трекере

Раздачей чего на трекере? Картинок? Картинки отдаёт сервер по сети при запросе в любом случае. Не важно что у Вас будет стоять для отдачи статики nginx/apache, но отдавать будет сервер, когда браузер будет делать запрос на получение картинки.

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

В имени картинки Вы собираетесь хранить метаданные о картинке? Ну это верный способ выстрелить себе в ногу.

Я вам предлагаю конкретную реализацию.

У вас в БД в таблице pictures четко сказано у какой картинки какой url, при этом на каждую картинку у вас может быть любое кол-во метаинформации, которая содержится в таблице picture_metadata. Соответственно поиск вы осуществляете по метаинформации, и возвращаете на клиент(в браузер) урлы картинок, которые соответствуют параметрам поиска, после чего уже рисуете (возвращенные строчки отдаете шаблонизатору). Если вы используете фреймворк на клиенте, то у вас скорее всего результат апи будет храниться в "модели" и настроить пагинацию будет просто(каждый фреймворк имеет свою реализацию пагинации).

Теперь по поводу того, что во вложение, во-первых сомневаюсь, что кто-то это писал руками (похоже на работу какого-то генератора статики). Во-вторых поиск, как вы можете сами видеть, авторы в js файл(dhtml_search.js) определяют массив длинной 33к строчки и файл js весит 8мб, а если картинок будет больше? Алгоритм поиска также простой, проходятся по массиву и проверяют вхождение строчки поиска в каждый элемент массива, 100мс уходит на такой проход на моем пк. Скажу так, это медленно. В общем это не рабочее решение в перспективе.

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

[hdma]

что вы имеете в виду, а то есть непонимание.

Имелась в виду раздача коллекции экслибрисов — посредством торрент-файла, по которым — после скачивания их желающими — можно было бы проводить поиск через файл из той же папки, полностью локально. То есть: скачались файлы у юзера в торрент-клиенте, он папку с ними открывает, запускает файл с поиском и непосредственно ищет по скаченному. А в именах картинок подумалось хранить метаданные о картинке, потому что длина имен это позволяет (это они в файле dhtml_search.js — планирую переименовать), а кроме того, чтобы их можно было просматривать и без поиска в оболочке — сразу понимая, какой файл о чём. Вроде, должно быть удобно.

Я вам предлагаю конкретную реализацию.

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

[EmperioAf]

hdma,
Если вы хотите чтобы пользователь локально искал файл, то использовать web технологии вообще не надо. А чем вам не нравиться поиск в проводнике windows? учитывая что у вас информация для поиска содержится в имени файла. если вид плиткой сделать, то и изображения прямо в проводнике будут выводиться. Т.е. вообще не понятно какая у пользователя в данном случае будет мотивация пользоваться сторонним клиентом для поиска изображений.

Далее. Проблема клиента написанного на web технологиях в том, что всё это запускается в браузере. А ваш браузер может получать данные только от сервера посредством http запросов(ну и локальные html, css, js он конечно может открывать). Браузер не может ходить за данными в нормальную базу данных используя драйвера ПК. В браузере у вас также нет модуля для работы с файловой системой, т.е. у вас нет возможности посмотреть какие файлы в каких папках есть...
Если уж вам так хочется решить эту задачу таким способом, то вы на правильном пути. Куча файлов с html кодом, а данные и логика работы с ними записаны в js файл.
Просто не ясен вопрос как вы собираетесь это всё поддерживать в рабочем состояние, если что-то будет меняться. Скажем добавили еще 200 картинок, вы будете руками их в массив в js файле забивать?
Если вы хотите писать собственный file explorer, то берите какой-нибудь нормальный язык со studio, где есть все компоненты для написания приложений под windows, например c# или delphi.

[hdma]

EmperioAf,
Дело в том, что поиск из Проводника будет на порядок дОльше прохродить и плюс результаты будут не точными, поскольку нельзя будет искать именно внутри определенных категорий. Тогда как в просмотрщике поиск будет вестись по строкам из файла js, а при наличии нескольких поисковых строк — давать возможность сужать и уточнять результаты за счёт категорий, в которых также можно указать разворачивающиеся списки с ключевыми словами, о которых можно будет сразу получать представление и которые не придется набирать. Всех этих возможностей иначе не будет. Ну, это как в скриптах сортируемых таблиц — где в какой-то колонке можно искать, в какой-то — разворачивать заданный список, а в какой-то задавать периоды "больше—меньше": для годов, например. Я использовал бы эти скрипты с таблицами как идеальный вариант — если бы после набора в поисковые строки, и по кнопке найти — результаты грузились в окно с пагинацией, а не существовали в том же файле.

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

[EmperioAf]

hdma,

а иначе, как понимаю, такой файл будет пытаться что-то сканировать и изменять свою базу

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

Дело в том, что поиск из Проводника будет на порядок дОльше прохродить и плюс результаты будут не точными, поскольку нельзя будет искать именно внутри определенных категорий

файловая система индексирует файлы
Как вы собираетесь форматировать название файлов?
author~jheronimus-bosch_picture~the-last-judgment_year~1482.jpg

А почему бы вам тогда не взять excel + access, в access кладете бд с такой же структурой которую я описал выше, только вместо url у вас будет path к файлу. А в excel на vba пишите нужные вам скрипты, так вы сможете и ходить в БД к access файлу(будет лежать рядом), и делать всякие крутые поиски, по любым метаданным. Да и картинки вы сможете тут же показывать в excel. И пагинацию вы сможете тут же делать.

Для решения конкретно поставленной задачи использование web технологий вас будет сильно ограничивать изначально. Web технологии предназначены в первую очередь для написания приложений, к которым пользователь получает доступ посредством сети. Из-за чего в браузере исполняемое приложение не имеет никакого реального доступа к компьютеру пользователя, который его использует(безопасность).

Стандартная модель использования web приложения, это когда клиент ходит по сети к какому-то серверу за данными, а вся работы с данными в основном описана на сервере, на клиенте описана логика отображения этих данных, и методы для получения их с сервера.
Конечно, вы можете написать и сервер с клиентом, и пользователь его будет запускать каким-либо образом локально, но тогда вам придется писать сервер на .Net и объяснять пользователю, что после запуска сервера, он должен открывать localhost:$port, где $port это порт, который слушает ваш сервер. Особенность в том, что серверный код имеет доступ к файловой системе компьютера на котором запущен, да и много к чему еще, например к драйверам баз данных(odbc, jdb, по сокету ходить в БД, в конечном итоге).