CLR - в некоторых случаях единственно возможный вариант. Например, если вам нужно в БД реализации Regex. Или что-то агрегировать, что MSSQL сам не умеет. Например, попробуйте сделать AVG по датам или временам. Не получится :-) Почему-то разработчики MSSQL посчитали, что "средняя дата" или "среднее время" - это что-то невероятное. Редкое - да, но не невероятное. Вот тут только CLR и выручит.
Строго говоря, с датой и временем - не совсем так. Можно откастировать в float, получить AVG, а потом откастировать обратно. Некрасиво, но работает.
Идея для собеседования: есть последовательность цифр с пропусками. Нужно наиболее эффективным способом выбрать все пропуски в виде диапазонов: 5-9 17-23 33 45-46
Годится для любого языка. А на диалектах SQL - так вообще огромный простор для творчества.
Как уже упоминал, бывают вопросы применимости. Вот для генерации значительного колва мусора в MSSQL - это готовый пример, остается только завернуть в CLR-хранимку. А вот взять томик Войны и Мир внутри СУБД не всегда возможно :-)
Добиться какой-то непредсказуемости, криптостойкойсти задачи не было. Вполне достаточно было уникальности и непохожести. Поэтому guid и крипттохеш. Нужен был просто генератор мусора, выполняемый относительно быстро.
А так-то - сделал бы сам генераторы гаммы по ARC4 в потоках и нарезал бы на строки. Тем более, что делал уже лет 10 назад :-)
Прелесть примера - в его тупой простоте и краткости. В этом вижу некую элегантность.
Вопрос применимости. Представьте себе ситуацию, когда вы не можете в решении использовать STL, например, собираете CLR-хранимку для MSSQL. А здесь вот - готовый код, только заворачивай в хранимку, и MSSQL получает генератор мусора в 4Гб за пару десятков секунд.
Согласитесь - код простой, понятный и короткий, свою задачу решает. Вот и славно :-)
CLR - в некоторых случаях единственно возможный вариант. Например, если вам нужно в БД реализации Regex. Или что-то агрегировать, что MSSQL сам не умеет. Например, попробуйте сделать AVG по датам или временам. Не получится :-) Почему-то разработчики MSSQL посчитали, что "средняя дата" или "среднее время" - это что-то невероятное. Редкое - да, но не невероятное. Вот тут только CLR и выручит.
Строго говоря, с датой и временем - не совсем так. Можно откастировать в float, получить AVG, а потом откастировать обратно. Некрасиво, но работает.
Мне хотелось избежать посимвольной генерации. Посчитал не элегантным.
Идея для собеседования:
есть последовательность цифр с пропусками. Нужно наиболее эффективным способом выбрать все пропуски в виде диапазонов:
5-9
17-23
33
45-46
Годится для любого языка. А на диалектах SQL - так вообще огромный простор для творчества.
Любопытно. Проверю на своем слабом PC, насколько улучшится время
Как уже упоминал, бывают вопросы применимости. Вот для генерации значительного колва мусора в MSSQL - это готовый пример, остается только завернуть в CLR-хранимку. А вот взять томик Войны и Мир внутри СУБД не всегда возможно :-)
Просто посчитал, что генерировать по-символьно - не элегантно.
Добиться какой-то непредсказуемости, криптостойкойсти задачи не было. Вполне достаточно было уникальности и непохожести. Поэтому guid и крипттохеш. Нужен был просто генератор мусора, выполняемый относительно быстро.
А так-то - сделал бы сам генераторы гаммы по ARC4 в потоках и нарезал бы на строки. Тем более, что делал уже лет 10 назад :-)
Прелесть примера - в его тупой простоте и краткости. В этом вижу некую элегантность.
Вопрос применимости. Представьте себе ситуацию, когда вы не можете в решении использовать STL, например, собираете CLR-хранимку для MSSQL. А здесь вот - готовый код, только заворачивай в хранимку, и MSSQL получает генератор мусора в 4Гб за пару десятков секунд.
Согласитесь - код простой, понятный и короткий, свою задачу решает. Вот и славно :-)
Попробовал сделать так, время уменьшилось на 1 секунду всего.
Проверил без распараллеливания. Отработало вдвое дольше
SHA512 дает нужную максимальную длину итоговых строк.