Блог

Поступил инетерсный вопрос - как округлить дату или время с помощью SQL запросов. Я почему-то эту тему в книге Transact-SQL обошел, поэтому расскажу здесь

Если нужно просто обрубить дату, то можно поступить так:

select dateadd(day, datediff(day, 0, GetDate()), 0)

Где-то я видел пример, в котором автор зачем-то прибавлял и отнимал дату '20000101':

select dateadd(day, datediff(day, '20000101', GetDate()), '20000101')

Результат идентичный предыдущему, а смысла в действии я не понял

Работая с большой базой данных и с кластером из серверов приложений, я видел уже достаточно много. Но недавно я просто ушел в шок, когда скрипты проверки данных показали, что на один банковский аккаунт было создано два пользователя. Я начал смотреть на записи пользователей и увидел, что они идентичны. Разница только в одном поле - время регистрации.

Пользователь заполнил форму со своими данными и отправил форму серверу. На сервере записи было установлено текущее время регистрации, и по каким-то причином код встал. Что-то подвисло почти на две минуты. У нас есть защита от повторной отправки формы, но каким-то макаром она не сработала и сервер получил второй запрос на регистрацию. Видимо это связано было с тем, что сервер протормозил с первым запросом.

У второй строки пользователя было установлено время регистрации и код пошел работать дальше. И тут самое интересное. Видимо первый сервер или другой поток, в котором спал первый запрос проснулся и две формы начали обрабатываться сервером одновременно. Система вставила в базу данных строку и установила время создание записей абсолютно одинаковым в плодь до миллисекунд. Ну ладно, такое возможно, что сервер вставляет две записи в одну и ту же миллисекунду. Я такого правда не видел, но допускаю.

Сегодня оптимизировал запрос, который до моего вмешательства работал 4 часа. Проблема была в том, что в нем не правильно использовалась функция isnull. Это очень удобная функция, особенно, если использовать ее в блоке SELECT, но ее нужно аккуратно использовать в блоке WHERE.

Я оптимизировал функцию, которая получала в качестве параметра необходимый тип данных. Если переменная равна NULL, то функция должна вернуть все данные.

Чтобы проще было следить за тем, что я говорю, давайте представим себе следующий запрос:

Вчера решил добавить на блог возможность закрывать комментарии для некоторых веток. Я долго ломался, делать эту возможность или нет. С одной стороны, я не хочу ограничивать читателей в праве высказаться, с другой стороны, иногда просто необходимо останавливать разговор.

Я как и прежде буду просто просить остановить жаркие споры, но не буду закрывать ветки. Новая возможность добавлена для веток, в которых можно мусорить. Например, вчера я создал ветку, в которой кто угодно мог задать вопрос и я отвечал на них. Ветка прожила один день, и я ее закрыл. Подобная ветка будет открыта через некоторое время снова. По ходу дела подобные вещи нужно устраивать чаще, но и нужно иногда останавливать, чтобы я мог передохнуть :).

Но не это самое главное. Я новую маленькую фишку добавлял вчера 3 часа. Тут же возникает вопрос, что я делал все это время? Справедливый вопрос. Вот как все происходило.

Блин, только выпустил обновление Библии С# и забыл в нем уточнить по поводу простых переменных и структур. Дело в том, что я написал, что их компилятор располагает их в стеке, но это не всегда правда. Так пишут все авторы, но если быть уж совсем точным, то компилятор не обязан располагать переменные в стеке. Обычная практика - он старается делать это. Я специально полез в интернет и увидел кучу статей, в которых пишут про то, что простые переменные будут в стеке.

Возьмем, например, статью .NET: Type Fundamentals еще за 2000 год из самого MSDN. В ней утверждается, что простая переменная будет расположена в стеке:

System.Int32 a = new System.Int32(5); When this statement is compiled, the compiler detects that the System.Int32 type is a value type and optimizes the resulting IL code so that this "object" is not allocated from the heap; instead, this object is placed on the thread's stack in the local variable a.

Когда я программировал в Delphi или на С++, то я ненавидел все эти библиотеки DLL, потому что чтобы выделить какой-то код в отдельный файл, получалось столько геммороя, что зад краснел от просиживания на стуле. Поэтому большинство своих программ я реализовывал в виде единого исполняемого файла.

В .NET подключение библиотек свелось к банальному указанию библиотеки в References и можно писать код одновременно и в библиотеке и в основном файле, где вы используете этот код. Никаких Export или Import функций больше не нужно объявлять и это счастье.

Мало того, что я обновил программу мониторинга раньше программы сетевых утилит, так я еще и выпустил новый модуль. Все новые модули всегда первыми появляются в программе сетевые утилиты, но этот год исключение. Впервые новый модуль появляется в программе Утилиты Web разработчика.

Новый модуль получил название SQL Stress и позволяет протестировать производительность SQL запроса. Недавно по работе пришлось работать над оптимизацией и пришлось искать готовое решение в интернете. Я не любитель держать на диске миллион программ, поэтому добавил возможность стресса запросов свои программы. Пока что я выложил в открытый доступ новую версию утилит WEB разработчика, но скоро обновлю и сетевые утилиты, где новый модуль будет так же доступен.

Смысл работы модуля прост – создается куча потоков и программа несколько раз подряд выполняет запросы, чтобы замерить скорость их работы. При этом на экран выводится среднее и максимальное время выполнения запроса, а так же информация об IO операциях сервером. В принципе все очень просто, но удобная утилита под подобные вещи никогда не помешает.

Я уже говорил, что у нас на работе многие (из тех, с кем я общался) пишут код в блокното-подобных редакторах кода и не используют Visual Studio. А зачем это нужно? Почему не использовать возможности Visual Studio, ведь его возможности могут реально быть полезными?

Да, хорошая среда разработки полезна и позволяет избавиться от перекомпиляции из-за опечатки. Но когда пишешь код без помощников, то постепенно количество опечаток уменьшатся, и приходится писать код более внимательно. Нужно уметь писать код удаленно на сервере, где нет практически ничего, кроме компилятора, блокнота и командной строки.

Умение писать в блокноте никогда не будет лишним. Не скажу, что это обязательно нужно уметь делать, но желательно. К нам на собеседования приходят достаточно умные ребята, с большим опытом работы программистом, но они проваливаются иногда только из-за того, что не могут писать код в блокноте без помощи Visual Studio. Это только кажется, что после 5 лет работы в продвинутых редакторах любой сможет написать код без их помощи. Практика показывает, что это далеко не так.

Давно я уже не выкладывал статей. Еще дольше не выкладывал новых статей. Сегодня (по моему времени уже вчера) я выложил новую статью MSN клиент на C#

Ajax - вполне хорошая технология и ее можно и даже нужно использовать так, где это надо. Ведь без перезагрузки всей страницы мы можем обновить ее часть и сэкономить пользователю трафик, не заставлять страницу мерцать и так далее и тому подобное. Но есть и недостаток - нельзя отойти на шаг назад с помощью кнопки Back (Назад) в браузере. Можно пойти на уловки, но все эти обходные пути больше издевательства, поэтому лучше не использовать (сугубо мое мнение).

Как узнать "где можно" использовать Ajax? Нужно понимать главный недостаток Ajax - не работает кнопка Back (Назад) в браузере. Если ты считаешь, что после выполненного действия пользователь может захотеть нажать кнопку назад, то ни в коем случае нельзя использовать Ajax.