Есть неопределенное количество данных x1,x2,x3...xN. Их количество может быть любым.
Есть справочник, в котором есть поля, например 100 полей, в которых находятся внесённые данные.
Необходимо найти элемент справочника, в котором есть либо все данные, указанные выше (x1,x2,x3...xN), либо какая-то их часть (по убыванию от их количества, когда они встречаются в элементе).
Пример:
Данные(x1,x2,x3...xN):
- x1 = перем1;
- x2 = перем2;
- x3 = перем3 и т.д.
Элементы сравочника:
- эл1: пр1, пп3, перем2, на3, ор1,
перем1;
- эл2: ор1, на2, на3, пр1,
перем1, пп3;
- эл3: перем3, ор1, пп3,пр1, пр1,
перем2;
- .....
- .....
- элN: на3, пр1, перем2, перем1, перем3, ор1
То есть, в элементе справочника элN нужные перепенные (максимальное количество) попались все. И т.д.

Ну удобнее, да и правильнее, если количество данных любое - значение полей хранить в подчиненном справочнике.
Тогда можно выбирать примерно так:

SELECT
  slave.parent as parent
  , count(*)
FROM
  slave
WHERE
  slave.value IN (data)
GROUP BY
  slave.parent
ORDER BY
  count(*) DESC
ORDER BY

Я не знаю, какое количество данных понадобиться пользователю. Сейчас 5, а позже 30. Набор этих данных каждый раз формируется разный, согласно мониторинга. Кроме того, пользователь может добавить другие данные, свои. Одно  радует, все эти данные входят в установленный перечень, и он неизменен. С подчинённостью сложно.
Например, установленный справочник данных составляет 275 элементов.
А справочник, из которого необходимо сделать выборку о наличие вышеуказанных данных уже сегодня составляет более 580 тыс. записей.

(2) Ну кажется тут даже лучше подчиненный с индексирование по полю Значению.

(2)100 реквизитов у вас у каждого элемента из 580 тыс, пусть даже и пустые. А подчиненный справочник будет содержать только добавленные данные.
И может даже не справочник, а регистр удобнее.

Нормально запрос на 100 реквизитов вы не напишите, тут придется явно все 100 перебирать. Можно текст формировать динамически, но все равно там они все будут. С подчиненной таблицей проще - соединение и подсчет количества соединений.

(3) это если там один тип значения. А так у ТС по задаче полный перебор по ссылка всегда и нечего стесняться собрать запрос, если это прямо описано в задаче
(4) да вроде просто. "либо все данные, указанные выше (x1,x2,x3...xN), либо какая-то их часть" гораздо проще обрабатывать на простой структуре хранения

(5) тип значения один у всех.

(5)Простая структура хранения - это создать избыточное количество реквизитов объекта?
Если б в запросе можно было перебирать реквизиты итератором, было бы просто, да.

(3) я не могу понять как это сделать. Когда я создаю новый элемент, то пользователь должен в его реквизитах указать (выбрать) значения из подчинённого справочника?
И что это даст?
Через два часа другой пользователь залезет в эту запись и выберет свой набор.
Или я что-то не допонял?

(8) Да почему. Выводи на форме элемента ТабличноеПоле, заполненное подчиненными.
Добавление новых значений - добавление новых подчиненных элементов. Т.е. вместо кучи реквизитов будет Таблица со строками.

(7) см (2) "Одно  радует, все эти данные входят в установленный перечень, и он неизменен. С подчинённостью сложно."
чуть изменяем "либо все данные, указанные выше (x1,x2,x3...xN), либо какая-то их часть" и получаем полную жопу на подчиненных

(10)Я, видимо, спросонья жопы не вижу) Вижу жопу в перечислении всех реквизитов в запросе и подсчете их количества. Либо количестве объединений. Хотя, 275 объединений вроде физически нельзя?
А вот с подчиненной таблицей запрос неизменен при любом количестве в наборе - (1)

(8)А разве в реквизите другой пользователь не может залезть и вбить свой набор?

+(11)К тому же, если заданный набор будет в произвольном порядке, то перебор в реквизитах "цэ из эн по ка" комбинаций превращается вообще в полный швах.