Есть пары строковых значений, А и В.
В процессе работы алгоритма надо составлять хранить множество пар, и периодически проверять в этом множестве наличие/отсутствие нужной. Какими средствами оптимальней сделать? Массивы, списки что-то не оч. удобны.

Соответствие.

Соответствие. В качестве ключа, например "А|В".

тз индексированная

полный перебор запросом

(2) усложняем задачу. Одно значение не строковое, а допустим ссылка на справочник.

(5) ВидОбъекта ("Справочник.Номенклатура")+ИдентификаторОбъекта(например УИД)

(5). И Ключ, и Значение в Соответствии могут быть любого типа, в том числе СправочникСсылка.

Индексированная таблица значений - самое очевидное

если значений два - я за соответствие
по Ключу А получаешь пару и проверяешь В на равенство Значению

(9) ну вот есть пары
А - 1
А - 2
Б - 1
Б - 2

По ключу А я получу какую из пар?

(10) По ключу А вы не запихнете в соответствие 2 значения.

если хэш по простому от пары не посчитать, то лучше тз

(10) тогда только (12)

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

В 1С проще всего использовать таблицу значений и добавить составной индекс по двум столбцам.

Если А-1 и 1-А это одно и то же значение, то перед поиском или добавлением делаем упорядочивание Левый<=Правый.

На мой вкус, в этой задаче лучше использовать соответствие соответствий.
Во всяком случае, для представления связей в графе - самое то. Примеры можно посмотреть здесь http://catalog.mista.ru/public/79285/ (Задача 3),
здесь http://catalog.mista.ru/public/460935/ (Задача 33),  здесь http://catalog.mista.ru/public/326983/ (Метод 3.4) и так далее.

Большим достоинством такого подхода является:
1) простота проверки наличия пары
Пара[А][Б] <> Неопределено
2) возможность хранения веса пары;
3) скорость удаления пары по сравнению с удалением пары в начале таблицы значений, когда приходится сдвигать вверх все последующие строки;
4) автоматическая защита от записи дубликатов.

Скорость поиска в таком соответствии и в таблице значений, индексированной по двум полям, практически одинакова, поскольку индекс в таблице значений построен (как я думаю) также на основе хэш-функции, а не на B-дереве.

Некоторым недостатком такого представления, с моей точки зрения, является определенная "корявость" записи новой пары, поскольку, если А во внешнем соответствии еще нет, то приходится создавать новое вложенное соответствие вот таким куском кода:
Если Пара[А] = Неопределено Тогда Пара[А] = Новый Соответствие
КонецЕсли.

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

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

(15) "1) простота проверки наличия пары
Пара[А][Б] <> Неопределено"
Оно же ошибку будет давать при отсутствии А

+(15)(16) Да, согласен, поторопился - пункт 1 в общем случае требуется уточнить:

1. Простота проверки:
Пара[А] <> Неопределено И Пара[А][Б] <> Неопределено
Второе условие не будет проверяться и давать ошибку, если А не будет во внешнем соответствии.

(0) Регистр сведений с двумя измерениями без ресурса

(15) Интересное решение, но не проще/быстрее один или два списка значений и двумерный массив (в котором наличие пары это 1 на пересечении номеров значений из списка)?

(18) Думаем есть какие то отличия от ТЗ/ТЧ из двух колонок?

В задаче так то 2 подзадачи:
1. Имея пару значений узнать содержится ли эта пара в множестве
2. Имея одно значение узнать какие есть пары с этим значением в множестве

Если требуется решать только подзадачу 1 то банальный хеш по паре значений (причем желательно симметричный) и пишем куда то.
В качестве хэша 2 строк можно взять попарное сложение кодов символов этих строк.

(14) Звучит как ультиматум :)
Варианта как минимум два, и решение зависит от задачи.
Если нам не нужно упорядочивание и/или поиск в интервале значений, то лучше Хеш.