powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / дали задачку, не могу найти подвох.
21 сообщений из 46, страница 2 из 2
дали задачку, не могу найти подвох.
    #37541689
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mniorlockyкстати, кто нить знает оптимальный индекс под такой запрос?Увели логин, или у меня битые ссылки памяти?

А вообще сразу вспомнил старое: 5582232, 6236024, как раз ветка с вами заканчивающая где-то здесь , и немного про индексы
Некоторые так и остались без ответа проигнорированы. Не думаю что ответят, скорее шапками закидают.
Да как ни крути при поиске пересекающихся периодов или по одной или по другой дате будет слишком объемный скан индекса
Да, мы ограничиваем ренж скана (больше или меньше определённой даты), но в общем случае у нас под условие попадает половина таблицы. Это как бы плохо.
Хочется идеального индекса.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541690
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Логика подсказывает что для большинства расчетных задач лучше всего будет подходить индекс по DateTo, дабы условие вида DateTo > @StartDate сразу отсекало значительную часть таблицы (т.к. на практике "законченых" событий значительно больше "еще не законченых")
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541700
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541702
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mnior locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее.Ссори, заглючило в нет направлении. Пойду спать.
Задача кажись нерешаема без скана никак. Отрезок-пустышка (без тела) сильно затрудняет разглядеть невидимые пересечения.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541720
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Mnior locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее.

А ишо сервер умеет делат index intersection...
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541722
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lockyкстати, кто нить знает оптимальный индекс под такой запрос?
Оптимальны ДВА индекса
d_begin
и
d_end
а сервер, могет быть, соизволит сделать index intersection.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541758
Фотография битый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DeColo®esaleks2Скока пустых слофф. Когда фсе элементарно
Код: plaintext
Select user_id from table where date_start<=@date_end and date_end>=@date_start;
+1
Select user_id from table where date_start<=@date_end and (date_end is null or date_end>=@date_start)
Или даже
Select user_id from table where ( date_start is null or date_start )<=@date_end and (date_end is null or date_end>=@date_start)
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541761
Фотография битый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
битыйDeColo®esпропущено...
+1
Select user_id from table where date_start<=@date_end and (date_end is null or date_end>=@date_start)
Или даже
Select user_id from table where ( date_start is null or date_start <=@date_end ) and (date_end is null or date_end>=@date_start)
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541783
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
битыйбитыйпропущено...

Select user_id from table where date_start<=@date_end and (date_end is null or date_end>=@date_start)
Или даже
Select user_id from table where ( date_start is null or date_start <=@date_end ) and (date_end is null or date_end>=@date_start)

Вам нужно сканирование таблицы? Нет?
Тады забудьте про
Код: plaintext
 is null or 
, лучше вставьте в таблицу вместо date_start=null date_start=<день_рождения_царя_гороха> и вместо date_end=null date_end=<день_конца_света>
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541791
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks2lockyкстати, кто нить знает оптимальный индекс под такой запрос?
Оптимальны ДВА индекса
d_begin
и
d_end
а сервер, могет быть, соизволит сделать index intersection. Как минимум, сервер может выбирать поиск по первому или второму индексу, в зависимости от заданных значений.

Так что даже без index intersection 2 индекса делать предпочтительнее.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541941
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks2Mnior... одним унифицированным полем даты будет намного эффективнее.А ишо сервер умеет делат index intersection...Вы явно не поняли. Если бы вы прошли по вышеуказанным линкам, то там говорится о одной колонке времени, а не о двух.

Mnior (сонный)Ссори, заглючило в не в том направлении. Пойду спать.Мда.
Mnior (сонный)lockyкстати, кто нить знает оптимальный индекс под такой запрос?
Отрезок -пустышка (без тела) сильно затрудняет разглядеть невидимые пересечения .Пришло мне в голову также на ночь глядя мысля. А утром ассоциативно вспомнилось про пространственный индекс . Думал как он работает и в принципе ночная мысля не столь фиговая оказалась. Естественно она топорная:

Как locky сказал, проблема в глубине скана. Поэтому нужно второе условие по дате.
Но "длина отрезка" периода, может быть гипотетически любой. Поэтому надо многослойный поиск разбитый по этим длинам (как непосредственно и работает пространственной индекс в 4-ре уровня). Сам по себе индекс (Duration, StartDate) не прокатит, но можно его заюзать для эмуляции такого подхода, и можно WHERE в индексах задействовать.
Т.к. врядли работники живут на работе - не сильно варуется диапазоны, то хватает два-три уровня ("плотность сетки" чтого типа GRIDS = (HIGH, LOW, LOW, LOW))

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
ALTER TABLE [TABLE] ADD Duration AS (DateDiff(Day,StartDate,EndDate)) PERSISTED
	
CREATE INDEX IX_Date1 FOR [TABLE] (StartDate) WHERE (Duration >=  1 )
CREATE INDEX IX_Date2 FOR [TABLE] (StartDate) WHERE (Duration <   1 )

	SELECT	*
	FROM	[TABLE]
	WHERE	    Duration	>=  1 
		AND StartDate	<= @From
		AND EndDate	>= @To
UNION ALL
	SELECT	*
	FROM	[TABLE]
	WHERE	    Duration	<   1 
		AND StartDate	<= @From
		AND StartDate	>= DateAdd(Day,- 1 ,@To)
		AND EndDate	>= @To
Можно и сам пространственный индекс задействовать. Создать эфемерную вычисляемую Geometry колонку (верно дядя Эйнштейн подсказал - время-пространство, всё едино).
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541947
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MniorТ.к. врядли работники живут на работе - не сильно варуется диапазоны ... Срань господня. Это по Фрейду?

не сильно варьируются диапазоны
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37541977
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks2lockyкстати, кто нить знает оптимальный индекс под такой запрос?
Оптимальны ДВА индекса
d_begin
и
d_end
а сервер, могет быть, соизволит сделать index intersection.
Пересекать два индекса, каждый длиной в полтаблицы - тоже не сахар.
В данном случае пересечение индексов будет накладнее чем ренж скан по одному из них
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37542067
Фотография битый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aleks2битыйпропущено...


Вам нужно сканирование таблицы? Нет?
Тады забудьте про
Код: plaintext
 is null or 
, лучше вставьте в таблицу вместо date_start=null date_start=<день_рождения_царя_гороха> и вместо date_end=null date_end=<день_конца_света>
Тут Вы правы, конечно, но коллегу попросили написать запрос, а не решить проблему кардинально, а про таблицу мы ничего не знаем. Можно, конечно, написать к задаче коммантарий, как у Вас...
Эти собеседующие часто такие формалисты
Напишет им тест кто-нибудь из Новосибирска, а они в Москве с его помощью тупо отсекают людей
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37542093
btm77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
правильно так

select [user_id]
from tbl
where date_start<=@date_end and вate_end>=@date_start
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37542114
Фотография битый
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
btm77правильно так

select [user_id]
from tbl
where date_start<=@date_end and вate_end>=@date_start
А если человек ещё работает, что у него в date_end ? Нет ответа.
А когда БД первоначально заполнялась, что поставили в date_start? Нет ответа.
Поэтому, предполагая злобность составителя теста, учёл возможность null.
Просто, потому что сталкивался с такими подвохами.
Комментарий по поводу производительности и индексов ( про которые тоже ничего не знаем ) действительно полезно дописать, но необязательно.
Задачу Вы формально решили, а при личном общении обсудите, если попросят.
Если бы составитель теста хотел проверить, знаете ли Вы, каким образом null учитывается в индексе, он указал бы сценарий создания индекса в условии.
Как-то так...
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37542139
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
btm77 (Alma-Ata)правильно так
Код: plaintext
select [user_id] from tbl where date_start<=@date_end and вate_end>=@date_start
2 года ждали, чтоб написать свой первый пост, и ... мимо. А 3 (три) дня назад было написано 11634248 .

Из анекдота- Чукча не читатель, Чукча писатель.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37561835
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тестирование 3х подходов:
Код + статистика
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
USE tempdb
GO
CREATE TABLE [dbo].[Period] (
	 [Object]	Int
	,[From]		DateTime
	,CONSTRAINT [PK_Period] PRIMARY KEY (
		 [Object]
		,[From]
	)
	,[To]		DateTime
	,[Duration]	Int		-- AS (DateDiff(Minute,[From],[To])) PERSISTED
	,[Period]	Geometry	-- AS Geometry::STLineFromText('LineString(0 '
--		+ Convert(VarChar,DateDiff(Minute,0,[From])) + ', 0 '
--		+ Convert(VarChar,DateDiff(Minute,0,  [To])) + ')', 0) PERSISTED
)
CREATE UNIQUE INDEX [UQ_Period_Day]   ON [dbo].[Period] ([From],[Object]) INCLUDE ([To]) WHERE ([Duration] <  1440)	-- 1.5 Gb
CREATE UNIQUE INDEX [UQ_Period_Other] ON [dbo].[Period] ([From],[Object]) INCLUDE ([To]) WHERE ([Duration] >= 1440)	-- 0 (фейл теста)
CREATE UNIQUE INDEX [UQ_Period_All]   ON [dbo].[Period] ([From],[Object]) INCLUDE ([To])				-- 1.5 Gb
CREATE SPATIAL INDEX [IX_Period_Sp]   ON [dbo].[Period] ([Period]) WITH (						-- 9 Gb
	 BOUNDING_BOX = (0,53121600,1,63113760)
	,GRIDS = (HIGH,HIGH,HIGH,HIGH)
)
GO
;WITH Random (Rnd) AS (
	SELECT	 Tan(-Rand(CheckSum(NewID()))*90)	-- Типа Гаусово
	FROM	 master.dbo.spt_values A
		,master.dbo.spt_values B
		,master.dbo.spt_values C
	WHERE	C.[type] = 'P' AND C.number < 10
), Data AS (
	SELECT	 Row_Number()OVER(ORDER BY (SELECT NULL)) % 10000				AS [Object]
		,DateAdd(Day,Row_Number()OVER(ORDER BY (SELECT NULL)) / 10000,'20010101 08:00')	AS [Date]
		,550 + [Rnd]									AS [Duration]
	FROM	Random
	WHERE	Abs([Rnd]) < 500
)	INSERT	dbo.Period
	SELECT	 [Object]
		,[Date]
		,DateAdd(Minute,[Duration],[Date])
		,Convert(Int,[Duration])
		,Geometry::STLineFromText('LineString(0 '
		+ Convert(VarChar,DateDiff(Minute,0,[Date])) + ',0 '
		+ Convert(VarChar,DateDiff(Minute,0,[Date]) + [Duration]) + ')',0)
	FROM	Data
-- 62 719 613
UPDATE STATISTICS dbo.Period
GO
SET NOCOUNT ON
SET STATISTICS IO ON
SET STATISTICS TIME ON
-- SELECT Min([From]), Max([From]) FROM dbo.Period
DECLARE	 @From		DateTime = '20010718'	-- '20070718'	-- '20170718'
	,@To		DateTime = '20010730'	-- '20070730'	-- '20170730'
	,@Object	Int
-- Пространственный
	SELECT	@Object	= [Object]	-- 947
	FROM	dbo.Period P	WITH(Index(IX_Period_Sp))
	WHERE	Geometry::STLineFromText('LineString(0 '
			+ Convert(VarChar,DateDiff(Minute,0,@From)) + ',0 '
			+ Convert(VarChar,DateDiff(Minute,0,@To  )) + ')',0)
		.STIntersects(P.Period) = 1
-- Пара ограниченных
	;WITH Query AS (
		SELECT	*
		FROM	dbo.Period
		WHERE	    Duration	>= 1440
			AND [From]	<= @To
			AND [To]	>= @From
	UNION ALL
		SELECT	*
		FROM	dbo.Period
		WHERE	    Duration	<  1440
			AND [From]	<= @To
			AND [From]	>= DateAdd(Minute,-1440,@From)
			AND [To]	>= @From
	)SELECT	@Object	= [Object]	-- 27
	FROM	Query
-- Тупой
	SELECT	@Object	= [Object]	-- 260
	FROM	dbo.Period
	WHERE	    [From]	<= @To
		AND [To]	>= @From

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
Таблица "extended_index_325576198_384000". Число просмотров 125, логических чтений 3067, физических чтений 0, упреждающих чтений 0
Таблица "Period". Число просмотров 0, логических чтений 487641, физических чтений 0, упреждающих чтений 0
   Время ЦП = 12329 мс, затраченное время = 931 мс.

Таблица "Period". Число просмотров 16, логических чтений 432, физических чтений 0, упреждающих чтений 0
   Время ЦП = 45 мс, затраченное время = 18 мс.

Таблица "Period". Число просмотров 17, логических чтений 197761, физических чтений 0, упреждающих чтений 0
   Время ЦП = 7380 мс, затраченное время = 474 мс.
--------------------------------------------------------------------------------
Таблица "extended_index_325576198_384000". Число просмотров 124, логических чтений 3061, физических чтений 0, упреждающих чтений 0
Таблица "Period". Число просмотров 0, логических чтений 488717, физических чтений 98, упреждающих чтений 54
   Время ЦП = 12321 мс, затраченное время = 971 мс.

Таблица "Period". Число просмотров 17, логических чтений 432, физических чтений 0, упреждающих чтений 0
   Время ЦП = 31 мс, затраченное время = 16 мс.

Таблица "Period". Число просмотров 17, логических чтений 78431, физических чтений 0, упреждающих чтений 0
   Время ЦП = 2965 мс, затраченное время = 199 мс.
--------------------------------------------------------------------------------
Таблица "extended_index_325576198_384000". Число просмотров 124, логических чтений 3088, физических чтений 0, упреждающих чтений 0
Таблица "Period". Число просмотров 0, логических чтений 488312, физических чтений 207, упреждающих чтений 27
   Время ЦП = 12201 мс, затраченное время = 984 мс.

Таблица "Period". Число просмотров 17, логических чтений 432, физических чтений 0, упреждающих чтений 0
   Время ЦП = 47 мс, затраченное время = 16 мс.

Таблица "Period". Число просмотров 17, логических чтений 6862, физических чтений 0, упреждающих чтений 0
   Время ЦП = 280 мс, затраченное время = 31 мс.
Индекс:ТупойПара ограниченныхПространственныйРазмер:1.5G1.5G(+0)9GВермя L:474(7380)18(45)931(12329)IO L:1977614323067+487641Вермя M:199(2965)16(31)971(12321)IO M:784314323061+488717Вермя R:31(280)16(47)984(12201)IO R:68624323088+488312
Недостатки:
1. Нельзя в WHERE индекса вешать даже PERSISTED вычисляемую колонку
2. Geometry (CLR) не могут быть PERSISTED
3. В пространственных индексах нет INCLUDE и не могут работать без обращения к кластерному

Вывод: Чем дальше в лес тем толще партизаны.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37562199
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MniorИндекс:ТупойПара ограниченныхПространственныйРазмер:1.5G1.5G(+0)9GВермя L:474(7380)18(45)931(12329)IO L:1977614323067+487641Вермя M:199(2965)16(31)971(12321)IO M:784314323061+488717Вермя R:31(280)16(47)984(12201)IO R:68624323088+488312Недостатки:
1. Нельзя в WHERE индекса вешать даже PERSISTED вычисляемую колонку
2. Geometry (CLR) не могут быть PERSISTED
3. В пространственных индексах нет INCLUDE и не могут работать без обращения к кластерномуВидно, что пространственный индекс в целом лучше тупого, но CLR не даёт ему полноценно развернуться.

Перестарался молодняк в M$ с универсализацией CLR среды (Джима Грея на них нет). Был бы нормальный встроенный тип, можно было развивать. А так это только игрушки.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37910540
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SomewhereSomehow неожиданно врывается в тему.
...
Рейтинг: 0 / 0
дали задачку, не могу найти подвох.
    #37913937
Mnior
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MniorSomewhereSomehow неожиданно врывается в тему.Безрезультатно.
...
Рейтинг: 0 / 0
21 сообщений из 46, страница 2 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / дали задачку, не могу найти подвох.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]