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

Здравствуйте!
Есть 30 тысяч изображений, по различным частям имен которых надо обеспечить поиск. Предполагается база со списком, из которой в html будут выводиться соответствия поиску, в котором есть необходимость в нескольких поисковых строках, для поиска в определенных частях имён изображений, напр. — Автор изображения | Название | Страна | Год создания. Есть ли что-нибудь подходящее для такой задачи, или может это как-то иначе лучше сделать?

База, это где?

MySQL рекомендую.

Почему?

В подключенном к html скрипте — это вариант, который я видел, но там нет поиска по нескольким параметрам. Еще про Clusterize.js узнал, который, как пишут, "способен отобразить таблицу с несколькими сотнями тысяч строчек — за счет разбиения элементов на кластеры, которые показываются на определенной позиции скроллинга и создания искусственных отступов сверху и снизу. Ограничения:"
Интересно, есть ли этот скрипт с возможностью поиска по колонкам из таблицы?

В скриптах не может быть физически никакой базы. Это может быть объект, текст, еще что-то, но не база.

Одна из самых распространенных и надежных субд

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

Ясно.

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

В отношении MySQL — есть ли примеры приблизительных соответствий условиям, о которых писал? Кстати, у меня использование предполагается локальное.

А MySQL, это реляционная база данных к JS отношения не имеющая, если только речь не о сервере и Node.js.

Для локального хранения http://html5.by/blog/localforage/
Либо более удобное в плане поиска и прочих операций с данными, это https://dev.w3.org/html5/webdatabase/, но с поддержкой ее пока туговато.

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

Какое расширение у файла с таблицей? смущает фраза "В подключенном к html скрипте"

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

MallSerg,
Вебкит доминирует, но все еще делит рынок

Как итог — нужен функционал, позволящий проводить поиск по 30 тысячам изображений, представленных в виде списка в объекте и подгружать на страницу в качестве результатов поиска. Как я представляю, имена из списка в объекте должны разбиваться на группы, чтобы работал множественный поиск, как по ссылке которую выше приводил. То есть, нужен множественный поиск и способность выводить результаты (со ссылками на изображения из той же локальной папки) частями.

Имел в виду: можно ли наладить на MySQL вышеизложенное. А насчёт "подключенного к html скрипта" речь была о ссылке на скрипт из тела html.

Например юзаешь мускул. Создаешь для каждого месяца отдельную таблицу. Т.е в таблице будут хранится картинки только на июнь месяца 2017, июль 2017 етк. И не, картинки а ссылки на них. Думаю ты понимаешь что картинки будут аналогично структурированы в папках. С помощью эскьюэль обращаешься по дате к нужной таблице и по переданным критериями забираешь дамп. С помощью сетевого протокола верхнего уровня передаешь сериализованный респонс, затем парсишь в штмл. Это если мы используем иксашэр, в народе аякс. Можно и серверным языком обойтись, но это не отменяет невозможности отрисовать браузеру сразу 30тыс. изображений, если запрос к базе без аргументов (не отфильтрован). А зачем? Есть давно придумали пагинацию, выводи первых 50 картинок на первой странице 51 - 100 на второй и т.д. Если хочется без пагинации, то пожалуйста то же выдумывать не надо. Аналогично при скролле получаешь из бд по 50 картинок и рисуешь подчищая дом дерево от старых картинок присваивая атрибуту стайл отступ от начало страницы равный высоте выборки.
Author | Caption | City | Link | Date
Rasy Summer in Minsk Belarus /images/6/2017/summer_in_minsk.jpg 6/2017

Андроидиы уже захватили все? :D

И зачем же плодить столько таблиц?

laimas,
Встречный вопрос. Если держать все в одной таблице, не будет нагрузка на проц и на дыцк?

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

Rasy,
Процессору не ведомо, с чем ему придется разбираться, он всегда нагружен. А вот 30 тыс. записей для СУБД, это пустяк, она не посчитает это нагрузкой. Но вот если разбить на части, а работа с данными далеко не банальное "взять часть", то нагрузка на СУБД может возрасти и очень.

Вроде подошел бы следующий пример на несколько мегабайт http://dabblet.com/gist/1528281 — но с кнопкой "Найти" и подгрузкой соответствующих запросу результатов.

hdma, алгоритм написан. Дело за малым - написать код.
laimas,
Если обратиться к таблице 5/2017 и выбрать строки, то никакой нагрузки не будет. А если придется выбирать полностью все, то да, придется все таблицы джоинить. Если будет много джоинов, то и скажеться на произвоидетьности. Ты про это нагрузку на СУБД говоришь? Ну ок, пусть создает одну таблицу.

Думаю вам известно, что такое нормализация БД, основываясь на которой и проектируется база. То что вы предлагаете, создавать за каждый месяц свою таблицу, никак не вписывается в принципы нормализации. И да, "если придется выбирать полностью все, то да, придется все таблицы джоинить", это нагрузка, а ведь не только "все", но и "периоды", "новые", "владельцы", и многое другое, что обязательно потребует объединений и подзапросов. В таком подходе больше проигрываем, чем выигрываем.

laimas,
Если опровергаешь, то предлагай.:) Мне принципы не интересны, главное чтобы не было большой нагрузки на серв. То что плодить таблицы плохая идея я понял. Не надо повторять.

А чего предлагать, структуру базы? Вы считаете, что автор сам хоть понимает чего хочет, чтобы можно было определиться с предложением? Я думаю, что нет. )
Но то что это должна быть одна таблица, это "однозначно" - Жириновский ©.

Это бесспорно. Так и есть, но я предложил алгоритм в соответствии со своими догадками.
Давай только без сарказма. Раз уже социализируешься на форумах, то с такими высказываниями никто с тобой не захочет контрибьютить:)

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

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

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

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

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

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

Делаем апи на любом серверном языке, скажем 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 массивы, но тогда вас ждут проблемы. Во-первых будет медленно грузиться, т.к. помимо логики работы с данными в вашем файле будут все данные возвращаться при каждом запросе к серверу. Во-вторых сомневаюсь, что вы сможете написать столь же эффективные алгоритмы выборки данных из плоских структур чем это уже сделано в реляционных БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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, по сокету ходить в БД, в конечном итоге).