Сложная, сложная EAV струкутра

У себя для поиска по списку пользователей использую такой подход (реализовано на данный момент частично, но подход должен быть понятен):

/**
 * Получение списка id пользователей по условиям
 *
 * @param array $filters Фильтры
 * @param array $order   Порядок сортировки
 *
 * @throws InvalidArgumentException
 *
 * @return array
 */
public function filter(array $filters, array $order = [])
{
    $fields  = $this->c->dbMap->users; // список имен полей таблицы пользователей с их типом
    $orderBy = [];
    $where   = ['u.id>1']; // нужное мне ограничение при любых фильрах
    // проверка и построение порядка вывода результата
    foreach ($order as $field => $dir) {
        if (! isset($fields[$field])) {
            throw new InvalidArgumentException('No sorting field found');
        }
        if ('ASC' !== $dir && 'DESC' !== $dir) {
            throw new InvalidArgumentException('The sorting order is not clear');
        }
        $orderBy[] = "u.{$field} {$dir}";
    }
    if (empty($orderBy)) {
        $orderBy = 'u.username ASC';
    } else {
        $orderBy = \implode(', ', $orderBy);
    }
    $vars = [];
    // проверка и построение условий запроса
    foreach ($filters as $field => $rule) {
        if (! isset($fields[$field])) {
            throw new InvalidArgumentException('No sorting field found');
        }
        switch ($rule[0]) {
            case '=':
            case '!=':
                $where[] = "u.{$field}{$rule[0]}?{$fields[$field]}";
                $vars[]  = $rule[1];
                break;
            case 'LIKE':
                $where[] = "u.{$field} LIKE ?{$fields[$field]}";
                $vars[]  = \str_replace(['*', '_'], ['%', '\\_'], $rule[1]);
                break;
            case 'BETWEEN':
                ...  // пишем свои обработки
                break;
            case ... // пишем свои обработки
                ...
                break;
            default:
                throw new InvalidArgumentException('The condition is not clear');
        }
    }
    $where = \implode(' AND ', $where);
    $sql = "SELECT u.id
            FROM ::users AS u
            WHERE {$where}
            ORDER BY {$orderBy}";
    $ids = $this->c->DB->query($sql, $vars)->fetchAll(PDO::FETCH_COLUMN);
    return $ids;
}

На вход подаем массив $filters в виде

$filters = [
    'username' => ['LIKE', 'Vi%'],
    'group'    => ['BETWEEN', 1, 10],
];

и массив $order в виде

$order = [
    'username' => 'DESC',
];

На выходе получаем id'шки записей удовлетворяющие фильтрам в нужном порядке.

Я не буду кидать сюда код, а просто изложу некие мысли. Описанный ниже подход успешно реализован, но код показать не могу.

1. Фильтр есть объект, он может принимать одно или несколько выбранных значений, а также может генерировать по этим значениям SQL-условие попадания записи под этот фильтр
2. Фильтры бывают разных типов, но у всех есть общая часть - принимать значение и генерировать SQL-условие
3. Создав базовый класс фильтр и расширяя его для каждого из типов фильтров, получим набор классов, которые умеют принимать значения и генерировать SQL-условие
4. (звездочка) Дополнительно может быть удобно сделать внешний вид фильтра также в классе фильтра. Тогда он не только будет принимать и хранить значение, но и взаимодействовать с пользователем. Но этот пункт возможно сделать не на всех моделях/архитектурах. Я его сделал, поскольку не использую CMS

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

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

Рисуем фильтры с выбранными значениями, ловим выбор пользователя, получаем набор экземпляров класса фильтр, собираем со всех фильтров условие SQL, объединяем условия SQL через AND между собой и получаем большущий такой WHERE для SQL запроса. Сохраняем в сессии, лимитируем, выдаем постраничный результат, все довольны.

Плюсы:

1. Удобно отлаживать каждый тип фильтр отдельно в рамках класса
2. Удобно модифицировать каждый тип фильтра - поменять внешний вид, поменять значения, брать значения из базы или из списка, или оттуда и оттуда
3. Удобно добавлять новые фильтры
4. Можно добавлять несколько фильтров одного типа, без всяких проблем

Минусы:

1. Довольно сильная абстрактная модель с иерархией классов может напугать неподготовленного программиста
2. Решение на AJAX может потребовать дополнительных знаний и навыков в работе с сессиями на стороне сервера, чтобы кэшировать выбор пользователя, плюс нужна хорошая подготовка в JS

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