|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
Mniorlockyкстати, кто нить знает оптимальный индекс под такой запрос?Увели логин, или у меня битые ссылки памяти? А вообще сразу вспомнил старое: 5582232, 6236024, как раз ветка с вами заканчивающая где-то здесь , и немного про индексы Некоторые так и остались без ответа проигнорированы. Не думаю что ответят, скорее шапками закидают. Да как ни крути при поиске пересекающихся периодов или по одной или по другой дате будет слишком объемный скан индекса Да, мы ограничиваем ренж скана (больше или меньше определённой даты), но в общем случае у нас под условие попадает половина таблицы. Это как бы плохо. Хочется идеального индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 02:34 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
Логика подсказывает что для большинства расчетных задач лучше всего будет подходить индекс по DateTo, дабы условие вида DateTo > @StartDate сразу отсекало значительную часть таблицы (т.к. на практике "законченых" событий значительно больше "еще не законченых") ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 02:40 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 03:55 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
Mnior locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее.Ссори, заглючило в нет направлении. Пойду спать. Задача кажись нерешаема без скана никак. Отрезок-пустышка (без тела) сильно затрудняет разглядеть невидимые пересечения. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 04:07 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
Mnior locky , т.е. вы согласны, что одним унифицированным полем даты будет намного эффективнее. А ишо сервер умеет делат index intersection... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 07:06 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
lockyкстати, кто нить знает оптимальный индекс под такой запрос? Оптимальны ДВА индекса d_begin и d_end а сервер, могет быть, соизволит сделать index intersection. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 07:10 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
DeColo®esaleks2Скока пустых слофф. Когда фсе элементарно Код: plaintext
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) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 09:01 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
битый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) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 09:03 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
битыйбитыйпропущено... 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
... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 09:27 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
aleks2lockyкстати, кто нить знает оптимальный индекс под такой запрос? Оптимальны ДВА индекса d_begin и d_end а сервер, могет быть, соизволит сделать index intersection. Как минимум, сервер может выбирать поиск по первому или второму индексу, в зависимости от заданных значений. Так что даже без index intersection 2 индекса делать предпочтительнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 09:46 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 11:11 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
MniorТ.к. врядли работники живут на работе - не сильно варуется диапазоны ... Срань господня. Это по Фрейду? не сильно варьируются диапазоны ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 11:15 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
aleks2lockyкстати, кто нить знает оптимальный индекс под такой запрос? Оптимальны ДВА индекса d_begin и d_end а сервер, могет быть, соизволит сделать index intersection. Пересекать два индекса, каждый длиной в полтаблицы - тоже не сахар. В данном случае пересечение индексов будет накладнее чем ренж скан по одному из них ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 11:31 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
aleks2битыйпропущено... Вам нужно сканирование таблицы? Нет? Тады забудьте про Код: plaintext
Тут Вы правы, конечно, но коллегу попросили написать запрос, а не решить проблему кардинально, а про таблицу мы ничего не знаем. Можно, конечно, написать к задаче коммантарий, как у Вас... Эти собеседующие часто такие формалисты Напишет им тест кто-нибудь из Новосибирска, а они в Москве с его помощью тупо отсекают людей ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 12:06 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
правильно так select [user_id] from tbl where date_start<=@date_end and вate_end>=@date_start ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 12:15 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
btm77правильно так select [user_id] from tbl where date_start<=@date_end and вate_end>=@date_start А если человек ещё работает, что у него в date_end ? Нет ответа. А когда БД первоначально заполнялась, что поставили в date_start? Нет ответа. Поэтому, предполагая злобность составителя теста, учёл возможность null. Просто, потому что сталкивался с такими подвохами. Комментарий по поводу производительности и индексов ( про которые тоже ничего не знаем ) действительно полезно дописать, но необязательно. Задачу Вы формально решили, а при личном общении обсудите, если попросят. Если бы составитель теста хотел проверить, знаете ли Вы, каким образом null учитывается в индексе, он указал бы сценарий создания индекса в условии. Как-то так... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 12:26 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
btm77 (Alma-Ata)правильно так Код: plaintext
Из анекдота- Чукча не читатель, Чукча писатель. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2011, 12:36 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
Тестирование 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.
Код: 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.
Недостатки: 1. Нельзя в WHERE индекса вешать даже PERSISTED вычисляемую колонку 2. Geometry (CLR) не могут быть PERSISTED 3. В пространственных индексах нет INCLUDE и не могут работать без обращения к кластерному Вывод: Чем дальше в лес тем толще партизаны. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.12.2011, 20:59 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
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 среды (Джима Грея на них нет). Был бы нормальный встроенный тип, можно было развивать. А так это только игрушки. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2011, 02:45 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
SomewhereSomehow неожиданно врывается в тему. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2012, 13:48 |
|
дали задачку, не могу найти подвох.
|
|||
---|---|---|---|
#18+
MniorSomewhereSomehow неожиданно врывается в тему.Безрезультатно. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2012, 09:24 |
|
|
start [/forum/topic.php?fid=46&msg=37541722&tid=1711221]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
53ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 170ms |
0 / 0 |