Это из футбола: "Кто дальше бьет, тот лучше играет"

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

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

На счет времени выполнения. Если в SQL 2000 не использовать в заголовке With recompile, то время запроса не зависит от объема процедуры.

Estets PVPНа счет времени выполнения. Если в SQL 2000 не использовать в заголовке With recompile, то время запроса не зависит от объема процедуры.
Не совсем согласен, большие процедуры обычно содержат работу с временными таблицами, а это может приводить к неоднократным перекомпиляциям процедуры в момент выполнения, с этим кстати связано правило вынесения деклараций всех #таблиц в начало процедуры. ИМХОО том, что в ходе выполнения запроса, может заново создаваться план выполнения (перекомпиляция процедуры), не знал. Хорошо бы ссылочку в то место, где об этом говорится. То что мне приходилось встречать в документации - это сначала план выполнения, загрузка в память (если этот план там еще не лежит) и затем выполнение.

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

Estets...с этим кстати связано правило вынесения деклараций всех #таблиц в начало процедуры. ИМХОТоже ИМХО, конечно, но хорошим тоном считаю декларировать переменые и таблицы в той части процедуры, где они используются. А в начало процедуры вынести только те декларации, которые используются по всему текусту, или в разных его местах. Это повышает читаемость процедур.

Еще, насчет количества процедур.

В сложной системе оно растет и растет и ничего с этим не поделать. В SQL 2000 нет практических ограничений их количества. Единственная проблема при большом количестве процедур - это их обслуживание. Во время разработки программисты еще помнят их имена и умеют искать. Но даже сами авторы, спустя год-два забывают как имена, так и где находятся эти процедуры. Поэтому в серьезной системе очень важно иметь возможность оперативного доступа к хранимым процедурам, хотя бы к их именам. А еще лучше - возможность их создания и редактирования.

Я приведу пример из БАС не потому, что это "самая-самая", а потому что больше ничего толком не знаю.

При обработке документов есть джельтменский набор процедур, которые требуется выполнить. Он небольшой. Условно можно назвать: инициализация, расчет, проводка, генерация, печать. Первая - реакция на действия пользователя во время работы. Вторая - выполнение расчетов по команде. Третья - действия, необходимые при проводке операции. Печать - если не достаточно системных средств, генерация - автоматическое создание документов. За несколько лет работы у меня этот состав не поменялся.

Так вот в каждой тиражной системе есть режим настройки операций (документов). Если в свойствах этих документов закрепить имена используемых хранимых процедур, то этим на 50% можно облегчить жизнь программистам внедрения и сопровождения. А если еще рядом с именем положить кнопку, по которой вызывается встроенный SQL-редактор с текстом используемой процедуры - то это 99% успеха программистов сопровождения.
Я уже не говорю о том, что когда встроенный редактор не находит в базе данных процедуру, он создает ее шаблон с указанным именем, списком параметров, наиболее популярными блоками.

Не сочтите это за рекламу, разве что чуть-чуть. Просто это (ИМХО) наиболее надежный способ обеспечить жизнь системе с большим количеством процедур.

Это пример описания свойств

А здесь реакция на нажатую кнопку. Дальше можно делать многое из того, что SQL Analyzer.

LSV PVPТоже ИМХО, конечно, но хорошим тоном считаю декларировать переменые и таблицы в той части процедуры, где они используются. А в начало процедуры вынести только те декларации, которые используются по всему текусту, или в разных его местах. Это повышает читаемость процедур.
Это помогает разбираться в коде человеку. А вот машина такого не любит.
Правильный тон для T-SQL это разнесение (по возможности) операторов DDL и DML в группы. Это даёт более стабильные и верные планы выполнения.
Так неправильно:
DML
DDL
DML
DDL
DML
DDL
....
Так правильно:
DDL
DDL
DDL
DML
DML
....Согласен с этим утверждением. Можно составлять так программы, что серверу будет легче. Только обычно предпочитаю упростить жизнь программисту. Чем нагляднее процедура, тем легче она воспринимается программистами, как авторами, так и теми, кому после этих авторов приходится заниматься с этими процедурами. Следовательно, ее легче сделать, а значит допустить меньше ошибок. В итоге, она будет работать лучше.

Programmer_Ortodox PVPА здесь реакция на нажатую кнопку. Дальше можно делать многое из того, что SQL Analyzer.
Мне понравилось! Следующим шагом могло бы быть введение интерпретатора встроенного языка,языка не "китайского" , а того, что учат в школеНаверное, Вы имеете в виду то, что пробел после запятой ставится, а перед - нет? И в конце предложения ставится точка? Предлагаю для изучения грамматики завести другой топик.

Programmer_Ortodoxхе-хе, имелся ввиду язык программирования!ОК. Принимается.

Estets Programmer_Ortodoxхе-хе, имелся ввиду язык программирования!
Попытки 1С перевести SQL на русский... что то коробит меня от этого ;)Ну вот, это же шутка Programmerа_Ortodoxа.

А вот серьезно, на счет языка. У меня есть опыт проведени курсов по SQL 2000 в местном универе. Синтаксис, основные операторы осваиваются за несколько часов. При этом не зависимо от специальности. Бухгалтера идут практически на уровне с прикладной математикой. Вся дальнейшая работа - это изучение программирования как такового. Поэтому совершенно не важно, на коком языке записывать программы. Важны технология, стиль, чувство компьютера, пользователя, ориентировка в задаче.

Estets PVPА вот серьезно, на счет языка. У меня есть опыт проведени курсов по SQL 2000 в местном универе. Синтаксис, основные операторы осваиваются за несколько часов. При этом не зависимо от специальности.
Кхе SQL единственный язык из 4-х команд S,U,I,D, ну из 6-ти если брать Drop и Create, и не брать Transact/PL составляющую.Не знаю, как на счет единственного, но на работая только на этом языке при наличии хорошого инструментария и хорошо ориентируюясь в предметной области можно делать сложнейшие системы. А какая цель изучения языка программирования? Это только инструмент, не более. Если он позволяет решать стоящие задачи, то этого достаточно. Заточите топор со всех сторон, легче будет рубить дрова?

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