Закончил на днях чтение книги “Хроники Безвременья. Записки бывшего начальника разведки” недавно ушедшего из жизни Леонида Владимировича Шебаршина.
Впечатление производит сильное. Но читается тяжело. В буквальном смысле “смех сквозь слезы”, в каждом афоризме чувствуется столько горечи, что иногда не по себе становится.
Как-то так сложилось, что с реляционными БД дело приходилось иметь не часто и не серьезно. Поэтому знания SQL у меня самые поверхностные и общие. Посему прошу опытных людей сильно надо мной не смеяться, полагаю, что для многих из вас то, что я расскажу ниже давно знакомо.
Если мне приходится работать с РСУБД, то довольной распространенной операцией является такая – поднять N строк из какой-то таблицы по какому-то условию, затем для этих N строк обновить столбец, который хранит дату и время обработки строки.
Пользуясь обычным SQL эта операция выполняется так: сначала выбирается N строк, на затем выполняется UPDATE. Причем, второй шаг можно делать по разному. Можно тупо в цикле для каждой строки вызывать UPDATE, а можно сначала ключи обновляемых строк поместить во вспомогательную временную таблицу, после чего запустить один UPDATE (этот подход, по моим наблюдениям, обычно работает быстрее, по крайней мере, в условиях работы с MSSQL через ODBC.).
Но недавно таки заглянул в MS-овскую документацию по T-SQL и обнаружил там интересную штуку, которая изрядно облегчает жизнь и ускоряет работу с БД – это команда OUTPUT, которая может использоваться внутри T-SQL-ых SELECT, INSERT, UPDATE и DELETE.
С ее помощью приведенный выше пример с выборкой и обновлением метки времени вырождается в более эффективную последовательность действий: сначала вызывается UPDATE для N первых строк, удовлетворяющих нужному условию, а в секции OUTPUT этого UPDATE предписывается поместить содержимое нужных мне столбцов измененных строк во временную таблицу. После чего делается простой SELECT из временной таблицы. Что-то вроде:
| UPDATE TOP(N) SET processed_at = GETDATE() OUTPUT inserted.column_1, inserted.column_2, ... inserted.column_N INTO #tmp_table WHERE ...; SELECT * FROM #tmp_table; TRUNCATE TABLE #tmp_table; |
Получается очень удобно, намного удобнее, чем через “обобщенный SQL”. Правда тут происходит более жесткая привязка к конкретной БД. Плюс еще особенности (в частности, порядок следования столбцов в OUTPUT должен в точности соответствовать порядку следования столбцов во временной таблице). Но если нет необходимости поддерживать разные типы БД, то вполне работоспособно.
PS. А еще в T-SQL есть какие-то table variables, с которыми я пока еще не разобрался, руки еще не дошли.
Увлекся дартсом аккурат два года назад – в апреле 2010. Правда, совсем уж серьезным занятием дартс стал полгода спустя, когда дома первая мишень появилась. За это время перепробовал разные упражнения на тренировках. В итоге пришел к выводу, что для меня реально работают всего два – это игра 170 и игра 501, но в 501 нужно обязательно играть с каким-нибудь противником. Желательно с настоящим и чуть-чуть сильнее, чем ты сам. Если же живого противника нет, то очень хорошо помогает программа n01, которая может имитировать соперников разного уровня мастерства.
Но кроме игры в 501 против реальных соперников (живого игрока или компьютерного “бота”) так же очень полезной оказалась игра в 501 на количество дротиков. Ставишь себе цель – выиграть лег за, скажем, 30 дротиков. Удается тебе это, значит лег выигран. Не удается, пусть даже ты закрылся 31-м дротиком, лег все равно проигран.
Такой способ не я придумал, о нем часто говорят, а те, кто не слышал, наверняка переизобретают его сами. В общем, довольно популярное упражнение для тренировок (реально работающее, кстати говоря).
Но есть в нем лично для меня большая проблема – быстрое подсаживание на коня ;) Ставишь себе рубеж в 27 дротиков – и тут же легов 20 подряд проигрываешь. Причем либо откровенно лажая по 2-3 броска на закрытие, либо закрываясь 28-м дротиком. И это сильно бесит. А уж когда такое происходит целую неделю подряд, то ваапще! Хочется все бросить.
Что, собственно, в прошлом году я и сделал. Поставил себе рубеж в 24 дротика, промаялся неделю и забросил. Хотя тогда 24 дротика явно были для меня недостижимы.
Сейчас решил повторить попытку. Вновь с рубежом в 24 дротика. Уже недели две держусь. По началу было все было мрачно. Сейчас стал привыкать. Но все равно напряг большой и соблазн сдаться велик.
Поэтому я решил поступить так, как поступил де Голль, когда собрался бросить курить – заявил об этом публично. Вот и я решил вести публичную статистику своей погони за 24-дротиками. Чтобы не было соблазна просто так втихоря забросить это начинание :)
Для этого в блоге, в правом столбце, после разной статистики, добавил два графика:
Первый показывает график изменения процентного соотношения выигранных матчей в каждой игровой серии. Т.е. провожу я тренировку, на которой, к примеру, играю 40 легов, 7 из которых выигрываю. Получается точка на этом графике, которая показывает, что в этот день я выиграл 14.89% легов. В другой день я выигрываю 8 легов из 26 и получается точка в 23.52%.
Второй показывает соотношение общего количества выигранных легов к общему количеству сыгранных легов.
Чего же хочется достичь в итоге? Я надеюсь за срок от полугода до года довести средний процент выигранных за игровую серию легов до 90% (т.е. кривая на первом графике должна в итоге стабилизироваться в районе 90% отметки). Полагаю, что на втором графике к тому времени должна будет сложится ситуация 50-на-50.
Если это получится, то следующей целью будет 21 дротик. Ну а если нет… Тогда, вероятно, нужно будет подумать об уходе из большого дартса :)
…на RSDN в форуме “Философия программирования”. Почти как в старые добрые времена. Запасаюсь попкорном.
К сожалению, всю малину портит главный проповедник светлого будущего исключительно в DSL-ных тонах. В его квалификации сомневаться явно не приходится, но нормально изложить свою точку зрения он так же явно не способен. Либо толкает какие-то революционные лозунги, либо:
“Я планирую это исправить”
“Ибо у меня на руках куча фактов”
“Ты несешь очевидный, для любого кто делал ДСЛ, бред”
“Это правильный вопрос. И на него довольно трудно сходу ответить. Но у меня есть мысли.”
Из чего лично мне совершенно не понятно, почему в языках общего назначения нет смысла и почему же DSL-и будут рулить.
Вообще, для такого рода идей лакмусовой бумажкой для меня является простой прием: я пытаюсь натянуть идею на задачу, которой в данный момент занимаюсь на работе. Последнюю неделю я занимался тем, что придумывал и реализовывал передачу информации из оперативной БД программы в историческую БД. Оперативная – это БД, которую активным образом использует компонент для своей работы. Историческая – это БД, по которой затем будет строится разнообразная статистика и отчеты.
Места для DSL я здесь не вижу. Проблема была в том, чтобы найти приемлимый алгоритм переноса. Когда он было найден, то без особых усилий был воплощен в C++ном коде. Делать какой-то помежуточный этап в виде языка с каким-то синтаксисом, его отображение в C++ный код и интеграция сгенерированного кода в существующий проект… Это все явно лишние телодвижения, ценность которых весьма сомнительна.
С другой стороны, время от времени возникают задачи, для решения которых DSL изначально напрашивается как самый лучший инструмент. Основная отличительная черта этих задач – это необходимость лаконичного описания желаемого результата в терминах предметной области. А уже из этого описания либо строятся килотонны примитивнейшего кода, либо его подхватывает какой-то интерпретатор, который руководствуется этим описанием в своей работе. Только вот задачи такие встречаются совсем не часто, по крайней мере у меня. В основном же с успехом используются языки общего назначения и уже давным-давно устоявшиеся DSL-и в виде того же SQL или регулярных выражений.
Приблизительно такую фразу сегодня вычитал в комментах одного из блогов.
На секундочку: Nikon D4 на данный момент в Москве стоит порядка 227000RUR (~$7500). И это только тушка. Ну а что, вполне себе нормальная цена для спонтанной покупки :)
В очередной раз в черепушку закралась мысля о том, что я чем-то не тем по жизни занимаюсь. Не могу себе таких капризов позволить. Лузер, не иначе :)
На RSND-е есть очень толковые люди. Один из них, kaa.python, ведет блог на житейские и рабочие темы. В котором в течении последних нескольких месяцев делится впечатлениями о своем пребывании в Корее и работе в корпорации Samsung. Наткнулся сегодня утром и с удовольствием прочитал (к сожалению, там не так много).
Смело рекомендую. Например, очень понравилось про организацию тестирования (да и планирования). Ну и еще чувствую себя просто сбрендившим трудоголиком по сравнении с корейцами ;)
