Блог

Магический тормоз

Продолжая тему оптимизации SQL запросов. Есть таблица пользователей и есть запрос, который ищет по этой таблице:

  SELECT поля
  FROM Members
  WHERE LastName LIKE @lastname and PostalCode = @postalcode

Индекс на поле LastName существует и работает. Если в качестве параметра передать 'Doe%', то запрос возвращает строки мгновенно и без проблем. Но стоит передать в качестве параметра 'rodriguez%' как запрос умирает напрочь. Умирает только на этой фамилии. Я тестировал сотни других, но они работают отлично.

Инициализация свойств объекта

Иногда часто после создания объекта нужно сразу же назначить кучу его свойств. Такое бывает если класс спроектировал начинающий программист или если класс реально сложный, типа формы. Если класс простой и оперирует всего парой свойств, то желательно создавать конструктор, который будет сразу же инициализировать все необходимые значения. Например, посмотрим на класс Size. Его можно проинициализировать так:

Size  s = new Size();
s.Width = 10;
s.Height = 10;

А можно воспользоваться другим конструктором:

SWF в Delphi

Кто-то через обратную форму задал вопрос, но забыл подписаться и оставить e-mail, на который я бы мог отправить ответ. Ну значит придется писать здесь. Вопрос следующий:

возможно ли использовать swf картинки в Делфи как кнопки?

Понятия не имею. Последняя версия Delphi, с которой я работал - была Delphi 2007 и продолжалось это всего три месяца. При этом я особо даже не вникал в эту версию и что она умеет.

Оптимизация запросов

Сори, но некогда писать. Второй день занимаюсь жестокой оптимизацией запросов. Один SELECT запрос выполняется очень часто и из-за пидxxxxxxеского SQL Server приводит к deadlock. Впервые вижу, чтобы SELECT запрос приводит к мертвой блокировке. Я все видел, но чтобы доводить до смерти. Это же банальное чтение данных, какого черта взаимноблокировать чтение.

Только что нашел проблему. Простая перестановка последовательности WHEN в CASE операторе уронила количество сканирований таблицы с 205000 до 18.

Что меня бесит в PHP

В PHP меня бесит то, что в нем конкатенация строк происходит через точку. Когда фигачиш кучу кода на PHP, а потом в том же файле переключаешся на JavaScript и в JavaScript функции пишешь 'Строка 1' . 'Строка 2', то этот код не работает, и ошибок нигде нет. JavaScript не генерирует ошибки, а на фоне большого кода PHP такая небольшая опечатка не кидается в глаза.

Кто знает, нафига в PHP сделали конкатенацию через точку? Лично мне кажется, что это сделано из-за автоматического преобразования. Если написать '22' + '22', то не смотря на то, что перед нами строки, они будут сложены как числа. И иногда это удобно, но все равно точка бесит, потому что во всех остальных языках, которые я исползую, конкатенация идет через символ сложения.

Оптимизация запроса с Датой

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

Один из запросов выполнялся 20 и более минут, хотя на все поля, по которым происходит поиск индексы есть. Даже не смотря на то, что одна из таблиц оооооччччень громадная, запрос не должен работать так долго. Это просто нереально.

Округление даты и времени в SQL Server

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

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

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

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

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

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

Идеальное время

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

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

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

Оптимизация или удобство SQL

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

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

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

Не обновляется база данных

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

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

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

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповедания, на русском или английском языке.

Пишите мне