Об этом написано в недостатках, а также упомянуто, что можно доработать алгоритм.
Не совсем так трагично, как вы описываете, потому что в этом случае объекты будут полностью или частично отсортированы, что на этапе досортировки она произойдет быстро
А вот вы в стеке аллокируете память. Это понятно, что быстрее, чем в куче. Однако, риски нехватки памяти (в данном случае переполнение стека) многократно возрастают. Может даже и не хватить для генерации 100 млн строк на маломощном PC. Когда вы так делаете - нет опасения развития таких неблагоприятных событий?
Я понял, вы из мира bigdata, поэтому полностью отрицаете серверную логику в СУБД. Однако, существуют другие миры, где серверная логика в СУБД очень развита. Например, многие банковские системы (АБС). Вы же не думаете, что когда в мобильном банке делаете платеж, а остатки у вас тут же обновляются, то эти остатки приходят из DWH ? Нет, это все крутится на основной БД АБС, которая в основном работает как OLTP, но на ней работает много серверной логики, и частично как OLAP для получения оперативной отчетности. Выписки по счету, например, - это она. А уже сбоку - ETL и DWH для отчетности аналитической, финансовой, регуляторной, которая вполне может подождать даже один день.
В следующей моей статье (пишется) будет понятно зачем понадобилось нагенерировать много строк на ходу :-) Выдернуто как отдельный интересный момент, как мне показалось.
Так на собеседовании и не должно быть ничего сложного.
А так: 1. Пусть кандидат попробует обойтись без явных циклов, оперируя множествами. 2. Пусть кандидат попробует обойтись без накопительного по одному диапазону списка диапазона, а получить сразу список, оперируя множествами.
В основном, конечно, такие задачки на собеседованиях по SQL. Но на ЯП тоже годится.
Насчет "медленный", пожалуй, не соглашусь. Это все-таки субъективная оценка. Мне производительность понравилась, вот и решил поделиться. Нисколько не сомневаюсь, что можно придумать и более быстрые алгоритмы (как и гораздо более медленные :-) ), дающие тот же результат.
Да, на hash join похоже, действительно.
Все ж таки разница есть. Я довел до практической реализации и получил хороший результат. Даже если "изобрел велосипед", как выясняется :-)
Упс. Не ожидал. Убрал упоминания.
Спасибо!
Если у вас так произойдет, это будет означать, что вы подобрали неподходящую функцию ранжирования
Не совсем так. Скорее под распределение данных нужно подобрать наиболее подходящую функцию ранжирования
Неравномерность и случайность - разные вещи, хотя и несколько коррелированы
Нет, конечно. Буфер выбирается из тех ресурсов, которые вы можете позволить.
Всяко бывает. Если, например, в страховую приходят клиенты, то их ФИО будут весьма распределены случайно
Ну и потом, там через всю статью протягивается мысль, что этот подход применим для частных случаев, подходящих для этого
Об этом написано в недостатках, а также упомянуто, что можно доработать алгоритм.
Не совсем так трагично, как вы описываете, потому что в этом случае объекты будут полностью или частично отсортированы, что на этапе досортировки она произойдет быстро
Крутяк
А вот вы в стеке аллокируете память. Это понятно, что быстрее, чем в куче. Однако, риски нехватки памяти (в данном случае переполнение стека) многократно возрастают. Может даже и не хватить для генерации 100 млн строк на маломощном PC. Когда вы так делаете - нет опасения развития таких неблагоприятных событий?
Я понял, вы из мира bigdata, поэтому полностью отрицаете серверную логику в СУБД. Однако, существуют другие миры, где серверная логика в СУБД очень развита. Например, многие банковские системы (АБС). Вы же не думаете, что когда в мобильном банке делаете платеж, а остатки у вас тут же обновляются, то эти остатки приходят из DWH ? Нет, это все крутится на основной БД АБС, которая в основном работает как OLTP, но на ней работает много серверной логики, и частично как OLAP для получения оперативной отчетности. Выписки по счету, например, - это она. А уже сбоку - ETL и DWH для отчетности аналитической, финансовой, регуляторной, которая вполне может подождать даже один день.
В следующей моей статье (пишется) будет понятно зачем понадобилось нагенерировать много строк на ходу :-) Выдернуто как отдельный интересный момент, как мне показалось.
Почему "костыль"? Прямо очень категорично. CLR - вполне себе штатные средства разработки в MSSQL, как и Java в Оракле.
Что-то даже не подумал, что этот код может показаться кому-то сложным. Учту. Спасибо.
С этим согласен. Но не всегда это возможно. Если делается CLR-хранимка для MSSQL, то там на плюсах особо не попишешь.
Так на собеседовании и не должно быть ничего сложного.
А так:
1. Пусть кандидат попробует обойтись без явных циклов, оперируя множествами.
2. Пусть кандидат попробует обойтись без накопительного по одному диапазону списка диапазона, а получить сразу список, оперируя множествами.
В основном, конечно, такие задачки на собеседованиях по SQL. Но на ЯП тоже годится.
Насчет "медленный", пожалуй, не соглашусь. Это все-таки субъективная оценка. Мне производительность понравилась, вот и решил поделиться.
Нисколько не сомневаюсь, что можно придумать и более быстрые алгоритмы (как и гораздо более медленные :-) ), дающие тот же результат.
Минусовать за мнение? Я бы не стал