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

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

понял. нужен был пример. это я просто в попыхах тему создал.

Вобщем допустим есть две таблицы:
<table>
<tr><td>Строка А</td></tr>
<tr><td>Строка А</td></tr>
<tr><td>Строка Б</td></tr>
<tr><td>Строка В</td></tr>
</table>

<table>
<tr><td>Строка А</td></tr>
<tr><td>Строка Б</td></tr>
<tr><td>Строка Б</td></tr>
<tr><td>Строка Г</td></tr>
</table>

вот как правильней будет? ниже два варианта

<CODE>ВЫБРАТЬ РАЗЛИЧНЫЕ * ИЗ таблица1
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ * ИЗ таблица2
</CODE>

<CODE>ВЫБРАТЬ * ИЗ таблица1
ПОЛНОЕ СОЕДИНЕНИЕ таблица2
СГРУППИРОВАТЬ ПО поле1
</CODE>

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

(3) тегов нет

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

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

(6) Не ври) DISTINCT

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

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

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

(9) а проверить?

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

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

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

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

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

(16) Может и Хэш таблицу применять

Используются разные алгоритмы sort unique/hash unique (distinct), sort group by/hash group by (group by).
Реализация алгоритмов может варьироваться от версии к версии.
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1015215&msg=14140858

http://msdn.microsoft.com/ru-ru/library/ms181714.aspx

{ HASH |ORDER } GROUP
Указывает, что агрегаты, описываемые в предложениях GROUP BY или DISTINCT запроса, должны использовать хэширование или упорядочивание.

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

(17) Я правильно понимаю, что DISTINCT работает так:
Hash group by - это:

1) Сортировка по агрегатным полям
2) Построение хеша по агрегатным полям (возможно одновременно с сортировкой)
3) Проход по таблице по алгоритму:

Если хешПредыдущейстроки<>хешТекущейСтроки Тогда
хешПредыдущейстроки=хешТекущейСтроки;
РезультирующаяТаблица.Добавить(ТекущаяСтрока);
КонецЕсли;

Sort group by - это:

1) Сортировка по агрегатным полям
2) Проход по таблице по алгоритму:

Если ПредыдущееПоле1<>ТекущееПоле1 ИЛИ... ПредыдущееПолеn<>ТекущееПолеn Тогда
ПредыдущееПоле1=ТекущееПоле1;
ПредыдущееПолеn=ТекущееПолеn;
РезультирующаяТаблица.Добавить(ТекущаяСтрока);
КонецЕсли;

(19) Gjcnjzyyj bcgjkmpe.
v8: Возможно ли ТаблицуЗначений по одной колонке свернуть, а по остальным сложить?

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

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

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

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

http://forum.infostart.ru/forum86/topic118274/?c=116&PAGEN_1=2

116 ответ

http://forum.infostart.ru/ajax/show_comment.php?t=118274&c=116

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

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

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

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

Для каждого стр из Соответствия Цикл
Вывод стр.Ключ
КонецЦикла

(27) Да.

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

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

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

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

(30) А чего там тяжкого?
Для sort group by нужно предварительно отсортировать.
Для Хэш таблицы она стротися по ходу.
Кстати нашел мои изыскания по сортировке слиянием на Delphi
http://rsdn.ru/forum/alg/683492.1
http://rsdn.ru/forum/alg/683492.1

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

Еще раз

Для каждого стр из Тз Цикл
Ключ=Стр[НаименованиеКлючевогоПоля];
Соответствие[Ключ]=1;
КонецЦикла

Для каждого стр из Соответствия Цикл
Вывод стр.Ключ
КонецЦикла

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

А вот если повторяющихся значений мало то тут рулит сортировка

(35) (36) Ясно

Еще раз, для закрепления.
Таблица:

НомерСтроки Номенклатура
1           Яблоки
2           Груши
3           Яблоки

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

Так?

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

для Distinct вообще берется HashSet. Там только ключи
http://msdn.microsoft.com/ru-ru/library/bb359438(v=vs.110).aspx

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

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

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

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

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

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

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

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