Позвольте мне кратко рассказать о том, что я пытался сделать, и о проблемах эффективности, с которыми я столкнулся:
По сути, я хочу, чтобы мои пользователи могли выбирать параметры для фильтрации данных из моих базы данных, то я хочу передать соответствующие данные, которые проходят эти фильтры от контроллера.
Однако эти фильтры запрашивают данные из нескольких разных таблиц (то есть около 5-6 разных таблиц), некоторые из которых довольно большой (как в 100к + рядов). Все эти таблицы связаны с тем, что я хочу показать, например, вот облигация, которая соответствует таким-то критериям, которая выпущена таким-то эмитентом, который должен соответствовать этим критериям, и т. Д.
От В конечном итоге мне действительно нужно около 100 строк после запроса на основе параметров, заданных пользователем, но мне кажется, что мне нужно смотреть на все в каждой таблице, потому что я не знаю, насколько строгими будут фильтры заранее. например, с начальным юниверсом, состоящим из 100 тыс. наборов данных, прохождение фильтров f1, f2 из таблицы 1 может оставить 90 тыс., но после прохождения через фильтр f3 таблицы 2, f4, f5, f6 таблицы 3 и так ..., мы могли бы в итоге получается 100 или менее наборов данных, которые передают эти параметры, потому что последние проверенные фильтры могут быть довольно строгими.
Как я могу go эффективно запрашивать эти несколько различных таблиц? Выполнение соединения между ними, похоже, даст некоторую временную сложность | T_1 || T_2 || T_3 || T_4 || T_5 || T_6 | где T_i - "размер" таблицы i.
С другой стороны, просто просматривая другие таблицы на основе идентификаторов тех, которые прошли предыдущий фильтр (например, id 5,7,8 пропускать фильтры в T_1, какой из этих идентификаторов затем проходит фильтры в T_2, затем какой из этих пропускает фильтры в T_3 и так далее) выглядит так, как будто он может (?) иметь временную сложность | T_1 | + | T_2 | + ... + | T_6 |.
Я относительно новичок в Ruby на Rails, поэтому я не совсем уверен во всех имеющихся в моем распоряжении инструментах, которые могут помочь с его оптимизацией, но в то же время время, я не совсем уверен, как лучше всего подойти к этому алгоритмически.