сгруппировать vs без повторяющихся #725120

что быстрее? как правильней?

для разных задач разные варианты

понял. нужен был пример. это я просто в попыхах тему создал. Вобщем допустим есть две таблицы: вот как правильней будет? ниже два варианта <CODE>ВЫБРАТЬ РАЗЛИЧНЫЕ * ИЗ таблица1 ОБЪЕДИНИТЬ ВСЕ ПОЛНОЕ СОЕДИНЕНИЕ таблица2 СГРУППИРОВАТЬ ПО поле1 </CODE>

мде.. где тут форматирование? какие теги-то?

тегов нет

Если в голом варианте- то различные быстрее.

НА уровне SQL нет разницы, оба ззпроса будут преобразованы к виду "group by"

Не ври) DISTINCT

оба варианта неверные )) достаточно просто -- Выбрать * ИЗ Таб1 ОБЪЕДИНИТЬ

Выбрать РАЗЛИЧНЫЕ * ИЗ Таб1

Когда-то слышал, что использовать "Объединить" вместо "Объединить Все" зло злостное.

а проверить?

Действительно.

СГРУППИРОВАТЬ имеет смысл при использовании агрегатных функций. РАЗЛИЧНЫЕ - ручками писать быстрее.

>>ГРУППИРОВАТЬ имеет смысл при использовании агрегатных функций - не "имеет смысл", а необходимо в этом случае. РАЗЛИЧНЫЕ и СГРУППИРОВАТЬ - совершенно разные команды 1С. Кто вам посоветовал их сравнить?

distinct неявно вызывает group by

вернее и то и другое делается через сортировку таблицы

Может и Хэш таблицу применять Используются разные алгоритмы sort unique/hash unique (distinct), sort group by/hash group by (group by). Реализация алгоритмов может варьироваться от версии к версии. { HASH |ORDER } GROUP Указывает, что агрегаты, описываемые в предложениях GROUP BY или DISTINCT запроса, должны использовать хэширование или упорядочивание.

>>вернее и то и другое делается через сортировку таблицы - варианты сортировки в SQL никакого прямого отношения не имеют к самим командам 1С. Как и к их быстройдействию в запросах 1С. Как правильно написал Serginio1 - если и есть минимальные отличия в способах сортировки SQRT в SQL, то они влияния такого не оказывают, как последующая обработка в самом 1С.

Я правильно понимаю, что DISTINCT работает так: Hash group by - это: 1) Сортировка по агрегатным полям 2) Построение хеша по агрегатным полям (возможно одновременно с сортировкой) 3) Проход по таблице по алгоритму: Sort group by - это: 1) Сортировка по агрегатным полям 2) Проход по таблице по алгоритму: Если ПредыдущееПоле1<>ТекущееПоле1 ИЛИ... ПредыдущееПолеn<>ТекущееПолеn Тогда ПредыдущееПоле1=ТекущееПоле1;

Gjcnjzyyj bcgjkmpe.

Что это за куски кода?

Ты делал универсальную Группировку для любых аггрегируемых типов штоле?

Я понимаю, как группировать ТЗ программно, см. (19, вариант 2) я спрашиваю, так ли это делает SQL, ибо мне на ум приходит только такой алгоритм, но может кибернетики придумали что-то хитрее.

Да и очень часто использую. Например для универсального списания по партиям

Хэш это берется хэштаблица которая и будет результатом. Ничего сортировать не надо

Зачем нам в результате хеш таблица?

sort group by работает по тому алгоритму, который я привел? Я был прав?

А нам нужны тоько неповторяющиеся значения Например Соответствие[Ключ]=1; КонецЦикла

Да.

Вы очень тяжко выражаете свои мысли.

Мы получили хеш таблицу, в ней есть повторяющиеся значения хеша, в случайном порядке. Мы должны: 1) Упорядочить таблицу по хешу и работать по алгоритму либо: 2) Обойти таблицу и собрать массив уникальных хешей, на каждом шаге проводя поиск в массиве.

в хэш таблице не повторяющихся значений

хэш таблица автоматически упорядочена. Для понимания рассматривай ее как соответствие

А чего там тяжкого? Для sort group by нужно предварительно отсортировать. Для Хэш таблицы она стротися по ходу. Кстати нашел мои изыскания по сортировке слиянием на Delphi

Нет в Хэш таблице повторяющихся значений Еще раз Для каждого стр из Тз Цикл КонецЦикла

Смысл такой если процент уникальных значений мал, то применяем Хэш таблицу, так как затраты на сортировку будут больше чем построение Хэш таблицы А вот если повторяющихся значений мало то тут рулит сортировка

Ясно

Еще раз, для закрепления. Таблица: НомерСтроки Номенклатура В хештаблице будут2 записи: 1)первая запись - хеш от слова "Яблоки", ссылка на строку номер 3. 2)вторая запись - хеш от слова "Груши", ссылка на строку номер 2. Так?

Номер строки - это не аггрегирующее поле, это идентификатор строки, RID.

для Distinct вообще берется HashSet. Там только ключи

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

>>Для sort group by нужно предварительно отсортировать. Для Хэш таблицы она стротися по ходу. - так я и не уловил, в чем разница, если 98% сравниваемых таблиц - это случай из ( 36), когда уникальных значений основная масса. И как тут выбрка по хэшу будет существенно быстрее?

Если нет агрегатов, DISTINCT, иначе GROUP BY

Хэш будет быстрее когда уникальных значений существенно меньше исходных данных. То есть количество строк в результирующей таблице значительно меньше, чем в исходных данных. Мы экономим на сортировке исходных данных. А вот когда количество строк в результирующей таблице составляет 98% то однозначно лучше сортировка. А вот процент раздела какой алгоритм лучше использовать только экспериментально.

SQL собирает статистику по уникальности аггрегирующих полей?

Ну запрос кэшируется. Могут кэшироваться и результаты от параметров. Задача БД выбрать оптимальный алгоритм и многое можно сделать учитывая статистику

для postgreSQL использовать Distinct - не рекомендуется