На этом сайте (http://www.sqlservercentral.com/) и не только Вы найдете статьи, рекомендующие избегать использования временных таблиц, чтобы повысить эффективность запросов. Я согласен с этим, но хотел бы добавить, что не всегда это удается сделать. Я работаю с несколькими очень большими базами данных на SQL Server (размер самой большой из них превышает 2.2 терабайта) и пришел к выводу, что в большинстве случаев могу обойтись без временных таблиц, хотя иногда они бывают полезны. В данной статье обсуждаются альтернативы временным таблицам с точки зрения производительности и обслуживания запросов.

Введение

Временные таблицы всегда прекрасно помогали разработчикам. Раньше, когда я использовал Access, я обычно создавал временные таблицы, которые удалял после решения задачи. При использовании SQL Server решить задачу можно гораздо проще. Не так ли?

Введение

Проблема, с которой я столкнулся, довольно известна. Я имею два триггера, которые должны отработать в предопределенном порядке, т.е. триггер A должен выполниться сначала, а после него должен отработать триггер B. Вы можете поинтересоваться, а почему бы не иметь один триггер, который объединит триггеры A и B в один триггер AB? Хороший вопрос. К сожалению, триггер A используется для репликации (For Replication), в то время как более поздний триггер - не для репликации, что определяет наличие именно двух триггеров.

Может быть вам покажутся удивительными результаты следующих арифметических операций:

declare @num1 numeric(38,10)
declare @num2 numeric(38,10)
set @num1 = .0000006
set @num2 = 1.0
select cast( @num1 * @num2 as numeric(38,10))

Дает: .0000010000
Вместо: .0000006000

Почему?

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

В Microsoft SQL Server 2000 появился новый тип table, используемый в языке Transact-SQL. Тип table подобен временным таблицам. Тип table можно использовать с целью сохранения результирующего набора для последующей обработки. Тип table можно использовать только для определения локальных переменных данного типа и возврата значения из функции пользователя. Основное использование типа table – временное хранилище для набора строк, которые возвращаются как результирующий набор таб-личнозначной функции.

Одним из вопросов, все чаще обсуждаемых мной в последние дни с клиентами или администраторами/разработчиками баз данных, является создание такой политики компании, которая бы описывала ряд стандартов, которым должны следовать при создании хранимых процедур для SQL server. С одной стороны, политика стандартов уровня компании или подразделения не должна быть столь ограничительной или "высеченной на камне", чтобы душить всякий творческий потенциал, который часто необходим для решения требований бизнеса, стоящих перед разработчиками. С другой стороны, она должна обеспечить такие рекомендации, которые ограничивали стиль кодирования таким образом, чтобы он не создавал проблем безопасности, падения производительности или проблем обслуживании в будущем.

Иногда приходится сожалеть о том, что в Transact-SQL Microsoft SQL Server нет такой структуры как Array (массив). Многие программисты SQL поддержат меня. Массив - одна из наиболее общих и часто используемых структур программирования. Действительно, T-SQL не предусматривает полностью функциональную структуру массива. Однако SQL 2000 ввел новую возможность, называемую переменной табличного типа, которая позволяет имитировать массив и/или использоваться вместо курсора в SQL Server.

В предлагаемой статье рассматриваются способы получения информации о физической структуре базы данных, отражение этой структуры в служебных таблицах и динамика работы SQL Server 7.0 с экстентами.

Введение

Горизонтальные, вертикальные, динамические и join фильтры дают возможность создать разделы данных, которые потом будут изданы. Фильтруя предназначенные для издания данные, Вы можете:
- Сократить количество данных, передаваемых по сети.
- Уменьшить размер баз данных на подписчиках (subscriber).
- Настроить публикацию и прикладные программы под индивидуальные требования подписчика.
- Исключить или уменьшить конфликты, за счёт того, что различные разделы данных могут быть реплицированы разным подписчикам (разные подписчики не будут модифицировать одни и те же данные).