Есть две ТЗ с одинаковой структурой - как быстрее всего получить различающиеся строки, и небольшое дополнение нужно получить отличающиеся строки только из второй таблицы.

+ метод желательно универсальный для ТЗ и СЗ, для упрощения в ТЗ такие колонки "Значение" и "Представление"

выбрать различные

(2) таблица/список могут быть невелики, запрос будет дольше чем перебор

(3) и в чем тогда вопрос? делай перебором...

(4) вопрос в ТЗ2 && ТЗ1

(0) В смысле, строки из второй, которых нет в первой?

Первую индексируем по Значение, затем цикл по второй.

(27) полное соединение по всем полям. если таблицы динамические - собираешь запрос в цикле

Таблицы мелкие, не более 100 строк, а чаще до 10, но их бесконечное множество

Другой метод - Слить две таблицы в одну с доп. колонкой "1", затем свернуть.

спроси vde69, у него есть алгоритм. Пользуюсь им уж лет пять.
быстрый.

Если таблицы неупорядоченные - то только созданием копии и вычёркиванием (особенно, если попадаются полные дубли).
Реально делается так:
Выбираем таблицу с меньшим числом строк и копируем один в один.
Далее, перебираем таблицу с большим числом строк и ищем соответствие в копии - если есть, то удаляем найденную строку из неё. Если не нашли - то запоминаем строку различия (в отдельную четвёртую таблицу).
В конце получаем в таблицы-копии те строки, которые есть только в меньшей таблице, а в четвёртой таблице - те строки, которые есть только в большей.
P.S. у меня по подобному принципу работает алгоритм отслеживания изменений в документах.

Если таблицы можно упорядочить - то пробежаться ленточным сравнением - начинаем сверху и идём до низу, выбирая и сравнивая строки.
Так как строки упорядочены, то для каждой строки задано сравнение - если в какой-то таблице обнаруживается строка, которая "выше" строки в другой - то она только в этой таблице - на следующий шаг сдвигаемся только по ней. Если строки одинаковые, то сдвигаемся по обеим таблицам.

(11)(12) единовременно сравниваются только 2 таблицы и результат нужен только от них.
Сравнение идет прошлой таблицы с текущей и так бесконечно, т.е. на всем протяжении работы с программой.

(13) >и так бесконечно

Пахнет кривым дизайном.

(14) предложите лучше

запрос, затем поле +1 и -1, объединение, сворачивание, отбор
или сразу отбор "не в"

(16) возвращаюсь к техническим данным - что быстрее запрос или перебор на 10-и строках и 2-х колонках ?

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

имхо запрос быстрее (надо тестить), но перебор проще написать (найти строки)

(13)
Массивы отсортированы?

(18) т.е. создание+уничтожение временной таблицы быстрее ?

+18 на 10 строках всё одинаково быстрое, если это не обновление таблиц на форме

(18)
Для неиндексированных таблиц спорное заявление

(19) нет, и время на сортировку жалко тратить, хотя конечно, если выигрыш во времени (и не мало важно ресурсов) на разбор отсортированных покроет расходы на сортировку, то можно и сортировать.

Для ускорения и снижения ресурсоемкости, таблицы даже были заменены на списки значений, но таблицы предпочтительнее (в СЗ теряю непомешавшую бы информацию)

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

Подумывал вообще о соответствии вместо тз или сз, тем более, что по сути "ключ" исходно уникален для каждой таблицы.
Таблицы - это список мди-окон - хендл и заголовок.

(24) понятно, что в конечном итоге перебор, но может быстрее реализован "внутре", чем когда прописан в коде 1с.

(25)
А какая разница - соответствие или ТЗ. У тебя ж явно вопрос не в простоте реализации стоит.
ИМХО стоит подумать о том, чтоб сравнивать на этапе формирования текущей ТЗ. Все равно обходишь данные пока пишешь в ТЗ

Откуда ТЗ получаешь?

(15) Я не знаю задачи.

(17) Свернуть на 10 строках должно быть быстро.

(27) вариант, пусть и несколько снизит универсальность.

(29) оно быстро конечно когда разово.
(28) рекурсивно получаю дочерние окна главного окна, правдо с некоторым "фильтром" - интерес составляют только с текстом заголовка, с пустым не нужны.

+1 к свернуть

(32) в одной ТЗ спецколонку заполнить единицами, во второй - нулями. Объединить, свернуть. НайтиСтроки где спецколонка = 0

(33) это известно, спасибо. Конечно померяю, но сомнения, что быстрее и менее ресурсоемко перебора будет на малых тз.

+ да и объединить тз в восьмерке не такая уж быстрая операция.

(33) + при условии, что нет дублей

(31) И зачем тут сабж? одного стека (массива) не достаточно?

И где вы вечно столько таблиц значений берете... Семерешкой попахивает.

(0) штатно, новая Колонка + заполнить 1/-1 объединить ТЗ через Заполнить и свернуть.
усё.

Хм... ТС какую-то вирусятину пишет ??? Скоро на всех 1С-ах страны "Для формирования ОСВ пришлите смс на номер бла-бла-бла )))"

Ну или ИТЗ использовать, там есть разность

(39) как в восьмерке объединить через заполнить ?

(42) ты предупреждай, что  в снеговике хоть :(
там проще запросом всё лепить

хорошо писать на T-SQL, там можно сделать

SELECT ...
EXCEPT
SELECT ...

Если пара HANLE-TITLE, то, скорей всего, HANDLE уникальный.
Потом, по HANDLE имеет смысл сортировать, так как это число - и должно работать быстро, а строки уже потом можно сравнивать.
Как вариант, объединить два параметра в одну строку и уже по ней сортировать таблицы (заранее), чтобы сравнение шло быстрее.

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

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

(0)
1)2-я таблица индексируется по всем полям.
2)Новая колонка - отметка
3)Создается структура со свойствами соотв колонкам
4) Для каждой строчки первой таблицы заполняется структура (заполнить значения свойств)
5) По структуре ищутся строки во второй таблице
6) Во всех найденных ставится пометка
7) Все строки без пометок 2 таблицы - искомые

Сложность алгоритма 2n, т.е. 2 прохода

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

(46)+
Этот алгоритм быстрее на порядок свертки и уж тем более помещения во временую таблицу

Интересно, если прикрутить дот.нет и использовать его LINQ. Наверное долго будут данные в дот.нет перегоняться. ВК наверное можно сделать. В фокспро было очень удобно SQL использовать для курсоров (рекордсетов в памяти).