select t1.[id заказа], sum(t2.[Стоимость]) as total_price
from СвязьТоваровЗаказов as t1
inner join Товары as t2
on t2.[id] = t1.[id товара]
group by t1.[id заказа]DECLARE @today as Date, @yesterday as Date;
Set @today = convert(date, getdate());
Set @yesterday = convert(date, dateadd(day, -1, getdate()));
SELECT m.Name, o.Created,
Count(DISTINCT(CASE WHEN Status = 'N' And o.Date = @today Then i.ID END)) as NewQ,
Count(DISTINCT(CASE WHEN Status = 'N' And o.Date = @yesterday Then i.ID END)) as YdNewQ,
Count(DISTINCT(CASE WHEN Status = 'W' And o.Date = @today Then i.ID END)) as WaitingQ,
Count(DISTINCT(CASE WHEN Status = 'W' And o.Date = @yesterday Then i.ID END)) as YDWaitingQ,
Count(DISTINCT(CASE WHEN Status = 'U' And o.Date = @today Then i.ID END)) as ProblemQ,
Count(DISTINCT(CASE WHEN Status = 'U' And o.Date = @yesterday Then i.ID END)) as YdProblemQ,
Count(DISTINCT(CASE WHEN Status = 'Z' And o.Date = @today Then i.ID END)) as CancelledQ,
Count(DISTINCT(CASE WHEN Status = 'Z' And o.Date = @yesterday Then i.ID END)) as YdCancelledQ
FROM Orders i
LEFT JOIN OrderItems o ON o.OrderID = i.ID
LEFT JOIN NomenclUS m ON m.ID = o.ProductID
WHERE i.Status <> 'Z' AND o.Created >= dateadd(day, -2, getdate())
GROUP BY o.Created, m.CatID, m.CatName,m.Name
ORDER BY o.Created, m.CatIDdef c(n, k):
t = min(n - k, k)
n_fact = [n-i for i in range(t)]
for i in range(t):
for j in range(len(n_fact)):
if n_fact[j] % (i + 1) == 0:
n_fact[j] = n_fact[j] // (i + 1)
break
result = 1
for j in range(len(n_fact)):
result *= n_fact[j]
return result
print(c(500, 1))
print(c(500, 5))
print(c(500, 10))
Вариант с not in:
1. получаем датасет по вложенному запросу и размещаем его например в tempdb
(тут имеем накладные расходы на хранение, т.к. tempdb в оперативке и чем больше откусишь ее, тем меньше останется для других пользователей/запросов)
2. для каждой записи внешней таблицы ищем вхождение во вложенный датасет, тут вариант полный перебор или хэш джойн или еще что-то.
3. в случае хэш джойн получим доп. накладные расходы на постороение хэш таблицы и на вычисление хэша для каждой записи внешней таблицы. Но есть плюс, т.к. вложенный датасет храниться в оперативке, то операции с ним выполняются быстрее чем с диском (хотя если диск SSD то разница не сильно большая).
Вариант с not exist при наличии индекса:
1. Тут возможна ситуация, что весь индекс или большая его часть закешированы в оперативке и тогда не будет множественных обращений к диску. А поиск в памяти по бинарному дереву (по индексу) может быть быстрее чем по хэш таблице, если учесть время необходимое для вычисления хэша от каждой записи внешней таблицы и на построение хэш таблицы.
2. Если индекс не закеширован то да, на поиск и загрузку страниц индекса с диска требуется больше времени чем поиск в хэш таблице в оперативке.