T-SQL, Databases, Development

Ранее я писал об использовании Stored Procedures, теперь пришёл черёд триггеров. В отличие от хранимых процедур, триггера я принял сразу. Очень удобная и полезная штука. Если вы хотите отследить вставку, изменение или удаление записи, то триггеры именно для этих задач. Как вы знаете, триггеры можут быть 3 типов(DML): на delete, insert и update; то есть триггер сработает на указанное действие с данными в таблице БД delete, insert или update , в зависимости от его типа. Выполняться он может до(before) или после(after) того действия(delete, insert или update) которое его вызвало. Триггеры before полезны, например,  для того, чтобы вы могли предупредить какое либо недопустимое, или несогласованное с логикой бизнесс процесса действие с данными. Он выполняется до вызвавшего его действия, а значит с помощью него можно это действие отменить, проверив данные на валидность с помощью sql statements вашего тригера. Триггеры after, выполняютя после действия, которое его инициировало и полезны, например для логирования изменений данных.

Читать далее…

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

Итак:

1. Вместо построчного удаления делайте массовое(сразу все строки, которые нужно удалить), т.к. при массовом удалении индекс претерпит изменения лишь раз, вместо постоянного передёргивания при построчном удалении. Например:

вместо

delete from tablename where field1=2

delete from tablename where field1=3

delete from tablename where field1=4,

лучше записать так -

delete from tablename where field1=2 or field1=3 or field1=4

2. Если при удалении вы уверены, что никто не будет делать запрос к таблице, то делайте «LOCK TABLE».

3. Если есть возможность перефразировать запрос на удаление указывая в разделе WHERE условие по полю первичного ключа, то целесообразно будет сделать именно так. Этот запрос будет не только быстрее, но и не будет блокировать таблицу.

Функции Cast() и Convert() дают возможность преобразовывать выражения одного типа в другой.

Для MSSQL Server синтаксис:

CAST ( expression AS data_type [ (length ) ])

CONVERT ( data_type [ ( length ) ] , expression [ , style ] )

Для MySQL:

CAST(expr AS type)

CAST() функция принимает данные одного типа и возвращает результат другого типа, как и CONVERT().

CONVERT(expr,type), CONVERT(expr USING transcoding_name)

Подробнее MS SQL http://msdn.microsoft.com/ru-ru/library/ms187928.aspx

и MySQL    http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html

Продолжаю тему оптимизации запросов по индексам начатую тут. Кстати синтаксис create index можно посмотреть тут для MS SQL http://msdn.microsoft.com/ru-ru/library/ms188783.aspx, и тут для MySQL http://dev.mysql.com/doc/refman/5.0/en/create-index.html.

Продолжаю советы:

Читать далее…

Одной из часто встречаемых проблем при работе с данными, является скорость вставки большого количества строк в таблицы баз данных. Можно использовать построчную вставку в цикле, но например для MySQL достаточно быстро выполнится insert с множественным указанием значений values, например :

insert into tablename(field1,field2) values(val11,val12) ,(val21,val22),(val31,val32),…

Читать далее…

Начиная с MS SQL Server 2005, появилась возможность запускать команды T-SQL на удалённом сервере благодаря новому ключевому слову «AT».

Читать далее…

Как вы уже догадались, речь пойдёт о хранимых процедурах(stored procedures). Когда я начинал работу с БД, не совсем понимал их суть и значимость. Но, спустя некоторое время, от MySQL я стал отказываться именно из-за отсутствия хранимок, пока, наконец, они там не появились. С ростом опыта, я пришёл к мысли, что большинстве приложений логику нужно выносить именно на БД, описывая иногда ОЧЕНЬ больше процедуры. Не всегда удаётся предугадать всё при построении БД. Спустя годы, приходится менять что-то в БД, добавляя новый функционал. И в этот момент очень спасают хранимки. Нет необходимости лопатить и перекомпилировать тонны старых кодов(давай-те ка признаемся сами себе на сколько хорошо мы документироум собственный код и как нелегко бывает вникнуть в его логику спустя месяцы, не говоря о годах). Нужно просто переписать некоторые процедуры, а в программу добавить лишь модуль, реализовывающий новый функционал.

Уже не буду даже упоминать о всех остальных плюсах stored procedures, таких как централизация и консолидация логики программы(многоразовое использование кода), уменьшение клиент-серверного трафика, повышение эффективности и скорости выполнения запросов, вынос вычислений на мощные сервера, вместо расчёта на локальном ПК и прочих плюсах.

Но как и у всего прочего, есть и свои минусы. Не всегда хорошо то, что при изменении лишь одной процедуры, все куски кода на неё ссылающиеся, будут ссылаться уже на эту, ИЗМЕНЁННУЮ процедуру. Но это тема другой беседы

Синтаксис T-SQL  (SQL Server)

Читать далее…