Sserj писал(а) 24. Октября 2019 :: 12:56:

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

Djelf писал(а) 24. Октября 2019 :: 16:18:

Спасибо, стало немного ясней.

Djelf писал(а) 24. Октября 2019 :: 16:18:

Не меняется время, видимо из-за того, что у меня в ON условия ещё (AND) и на другое(ие) поля в бОльшей таблице.

Djelf писал(а) 24. Октября 2019 :: 16:18:

Вот тут странно, что не меняется время выполнения совсем и не ругается на синтаксис. COLLATE BINARY надо добавлять в конце строки ON после всех условий (ну AND, OR, etc) или после каждого элементарного условия?

Djelf писал(а) 24. Октября 2019 :: 16:18:

Я именно это и имел ввиду когда спрашивал, что может так и должно быть. Вообще, надо сказать, в типовом ТиСе регистры и ПартииНаличие в частности "сархитектурен" просто безобразно. К сожалению замена структуры регистров рассматривается мной в последнюю очередь из-за объёма базы, неохота всё перепроводить, хрен его что может вылезти за все года  Просто, хотя бы: ни в одном регистре, кроме партий, не привязываются строки, что не даёт однозначно связать движения из разных регистров, хотя может я и не прав - это не нужно. т.е. я пока осторожно пробую возможности прямых запросов. И мне очень нравится. 1sqlite - просто шикарен. Текущая реализация SQL в скулайте очень хороша, все эти оконные функции, фильтра, группировки - глаза разбегаются и слюна течёт.

Теперь по делу. Вот такой запрос делает тоже самое, но на порядок быстрее предыдущего. вкратце, я джойню не регистры, а подзапросы из них

	|--EXPLAIN QUERY PLAN
	|SELECT
	|	Д1.Номенклатура [Номенклатура :Справочник.Номенклатура]
	|	,Д1.LINENO LINENO
	|	,Д1.Фирма [Фирма :Справочник.Фирмы]
	|	,Д1.МОЛ [МОЛ :Справочник.ФизЛица]
	|	,О1.Склад [Склад :Справочник.Склады]
	|	,Д1.Поставщик [Поставщик :Справочник.Контрагенты]
	|	,П1.Покупатель [Покупатель :Справочник.Контрагенты]
	|	,Д1.Движение
	|	,Д1.Приход
	|	,Д1.Расход
	|	,Д1.СуммаУпр
	|	,Д1.Партия [Партия :Справочник.Партии]
	|	,Д1.ДатаПартии
	|	,Д1.СтатусПартии [СтатусПартии :Перечисление.СтатусыПартии]
	|	,П1.Себестоимость
	|	,П1.Продстоимость
	|	,Д1.Документ [Документ :Документ]
	|FROM (
	|	SELECT
	|		Движения2.Номенклатура Номенклатура
	|		,Движения2.LINENO LINENO
	|		,Движения2.Фирма Фирма
	|		,Движения2.МОЛ МОЛ
	|		,Партии.Поставщик Поставщик
	|		,Движения2.Количество * (1 - Движения2.DEBKRED * 2) Движение
	|		,Движения2.Количество * (1-Движения2.DEBKRED) Приход
	|		,Движения2.Количество * Движения2.DEBKRED Расход
	|		,Движения2.СуммаУпр СуммаУпр
	|		,Движения2.Партия Партия
	|		,Движения2.ДатаПартии ДатаПартии
	|		,Движения2.СтатусПартии СтатусПартии
	|		,Жур2.IDDOCDEF||Движения2.IDDOC Документ
	|
	|	FROM
	|		[Регистр.ПартииНаличие] Движения2
	|	INNER JOIN [Журнал] Жур2 ON Жур2.IDDOC = Движения2.IDDOC AND Жур2.DATE BETWEEN :Дата1 AND :Дата2
	|	LEFT JOIN [Справочник.Партии] Партии ON Партии.ID = Движения2.Партия
	|) Д1
	|LEFT JOIN (
	|	SELECT
	|		ОстаткиТМЦ.Номенклатура
	|		,ОстаткиТМЦ.Фирма
	|		,ОстаткиТМЦ.Склад
	|		,Жур.IDDOCDEF||ОстаткиТМЦ.IDDOC Документ
	|	FROM
	|		[Регистр.ОстаткиТМЦ] ОстаткиТМЦ
	|	INNER JOIN [Журнал] Жур ON Жур.IDDOC = ОстаткиТМЦ.IDDOC AND Жур.DATE BETWEEN :Дата1 AND :Дата2
	|) О1 ON Д1.Документ = О1.Документ AND Д1.Номенклатура = О1.Номенклатура
	|LEFT JOIN (
	|	SELECT
	|		Продажи.Номенклатура
	|		,Продажи.LINENO
	|		,Продажи.Фирма
	|		,Продажи.Поставщик
	|		,Продажи.Покупатель
	|		,Продажи.Себестоимость
	|		,Продажи.ПродСтоимость
	|		,Жур3.IDDOCDEF||Продажи.IDDOC Документ
	|	FROM
	|		[Регистр.Продажи] Продажи
	|	INNER JOIN [Журнал] Жур3 ON Жур3.IDDOC = Продажи.IDDOC AND Жур3.DATE BETWEEN :Дата1 AND :Дата2
	|) П1 ON Д1.Документ = П1.Документ AND Д1.Номенклатура = П1.Номенклатура AND Д1.Поставщик = П1.Поставщик
	|ORDER BY Д1.Номенклатура, Д1.Партия, Д1.LINENO
 

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

добавлено: из двух последних подзапросов нужно выкинуть неиспользуемые поля LINENO и Фирма, что несколько уменьшает RAM

Arbuz писал(а) 25. Октября 2019 :: 09:37:


Насчет группировки я не сильно прав был.
Запрос выполняется чуток по другому.
Вот кусок полного плана.
Выделенный кусок выполняется в цикле.
Т.е. выше мы получили список всех iddoc и товаров.
А потом для каждого iddoc и товара просматриваем три таблицы последовательно.
Т.е. приходится дергать индекс.
В твоем втором случае надо смотреть отличие...

MATERIALIZE создает временную таблицу
COVERING INDEX - покрывающий индекс, индекс по нескольким полям

А быстрее стало быстрее потому что в первом запросе ставился фильтр по документу, а потом перебором вычислялась номенклатура (вот это на самом деле замедляло). Во втором запросе тупо сваливаем все данные во временную таблицу, индексируем по документу и номенклатуре и объединяем таблицы.

В принципе можно еще попробовать через union all попробовать объединять таблицы...

Arbuz писал(а) 25. Октября 2019 :: 11:49:


Творчески

Ну вот мы знаем что при группировке
GROUP BY Выборка.Номенклатура,Выборка.Фирма,Выборка.Документ
Склад у нас фактически уникальный
Но не везде он есть. Где нет, заполняем как NULL
Все UNION во вложенной таблице Выборка
А в первом SELECT пишем max(Выборка.Склад), или min, NULL туда не попадет ни так ни сяк.