(Возврат на основную страницу)
Команда программистов Microsoft SQL Server извлекла горький урок из работы над SQL Server 2005: клиенты не желают пять лет ждать выхода новой версии. Отныне и навсегда новый режим, названный инициативой доработки программного обеспечения (Software Reengineering Initiative, SRI), гарантирует выход новой версии каждые два года независимо от того, готовы новые возможности или нет, как заявил Марк Соуза, возглавляющий команду SRI.
Для многих пользователей, подписавших лицензионную модель Software Assurance летом 2002 года, ожидание SQL Server 2005 было особенно болезненным. Одно из разрекламированных преимуществ условий передачи прав на программное обеспечение заключалось в том, что покрывалась стоимость перехода на новую версию. Однако некоторые аналитики указывали, что здесь крылся потенциальный подвох для клиентов.
Три года спустя эти предостережения сбылись, ведь в конце первого периода действия соглашения новых версий для серверов Exchange и SQL Server не было и в помине.
После того как в начале ноября 2005 г. наконецто был выпущен SQL Server 2005, Microsoft заявила, что из случившегося сделаны выводы. Беседуя с ZDNet (Великобритания) на форуме IT Microsoft, Соуза сказал: «Мы последовательно позаботимся обо всех своих клиентах, которые ожидали более раннего выхода новой версии. Мы многое уяснили, но одно следует помнить всегда — это не просто выпуск новой версии, но еще и сопровождение». По его словам, важный урок для команды программистов заключался в том, что необходимо изменить процессы разработки так, чтобы гарантировать двухгодичный цикл выпуска новых версий: «Выпуск SQL Server будет подобен поезду с двухлетним интервалом движения. Если какаято новая функциональность не будет готова, она попадет на следующий поезд. В SQL Server 2005 многие возможности были выполнены на 80%, но в силу нашей методологии проектирования продукта мы просто не могли их выбросить».
Возможно, самые большие изменения в SRI коснулись процесса тестирования. Соуза рассказал: «Раньше каждую отдельную функциональную возможность разрабатывали и тестировали индивидуальные группы, а затем нам приходилось подвергать тестированию все другие компоненты, которые ею пользовались. Одним из примеров такого подхода служит database mirroring, которое не вошло в первый выпуск SQL Server 2005, но теперь готово к поставке в первомвтором квартале 2006. Мы построили этот компонент, но было необходимо убедиться, что он взаимодействует с другими компонентами. После добавления еще нескольких новых возможностей процесс тестирования просто «взорвался». У SQL Server 2005 больше новинок, чем у любой другой новой версии, так что матрица тестирования стала как никогда огромной».
Изменился и метод работы над проектом. «Вы трудитесь в одной команде, но работаете с проектировщиками, занимающимися определенной функциональной возможностью, до тех пор, пока она не будет доведена до конца. Так проще узнать, попадет функциональная возможность в конкретный выпуск или нет», — добавил Соуза.
Этот результат кладет конец идее большого выпуска. «Сначала мы наметим темы каждого конкретного выпуска, например нулевые затраты на администрирование, — говорит Соуза, — а затем составим список действий и постараемся выполнить как можно больше до истечения срока завершения». Эта идея, которую впервые проводит группа SQL Server, привлекает внимание групп, разрабатывающих другие программные продукты в Microsoft. Она явилась прямым результатом пятилетнего ожидания выпуска последней версии SQL Server. «За последние пять лет Oracle дважды осуществляла выпуски, как и IBM. Но если взглянуть на них, видно, что они посвящены небольшим темам, и клиенты легко к этому приспосабливаются», — заметил Соуза.
В этой статье мы познакомимся с функциями и операторами для работы с элементами. Мы изучим функции .FirstChild, .LastChild, .FirstSibling и .LastSibling, детально рассмотрев их синтаксис и данные на выходе. Мы изучим работу с этими функциями в упражнениях, а потом рассмотрим наборы данных, возвращаемые в каждом из примеров.
Мы потратим некоторое время на «знакомство с семьей» (я имею в виду «семейные» функции), подразумевая, что функции и операторы, которые составляют эту группу, включают:
.Parent;
.Children;
Ancestor();
Cousin();
.FirstChild;
.LastChild;
.FirstSibling;
.LastSibling.
Метафора семьи подходит для этой группы, потому что данные функции выполняют операции над измерениями, иерархиями и уровнями по принципу, напоминающему движение по генеалогическому древу. Мы сосредоточимся на функциях для работы с элементами, хотя есть и другие функции, похожие на «семейные», которые возвращают наборы данных.
Эта статья включает:
ознакомление с функциями .FirstChild, .LastChild, .FirstSibling и .LastSibling;
изучение синтаксиса для использования каждой функции;
иллюстрированный пример применения функций в практических упражнениях;
краткое обсуждение результатов выполнения запросов MDX, которые мы получим в практических примерах;
дальнейшее изучение выражения WHERE и его специфики в измерениях с продольными срезами данных;
иллюстрации к использованию комбинаций «семейных» функций;
применение ключевых слов NON EMPTY для удаления пустых пересечений, возвращаемых результирующими наборами данных.
Как обсуждалось в статье «Функции членов в MDX: «семейные» функции» (№ 5 журнала за 2005 год), многие функции для работы с элементами, особенно из «семейной» группы, позволяют выполнять операции, основанные на относительной позиции элемента, либо выше элемента («над» элементом, на котором выполняется функция), либо ниже («под» элементом, на котором выполняется функция) в иерархии измерений. Как и большинство подобных функций, «семейные» помогают делать запросы MDX проще и компактнее.
Декларативная ссылочная целостность (Declarative Referential Integrity, DRI) появилась еще в версии SQL Server 6.5, однако она не обрабатывает неординарные случаи, когда необходимо иметь внешние ключи более чем к одной таблице. Доктор Том Моро — сам человек неординарный — воспринял это как вызов.
Идея большинства моделей данных состоит в том, что создаются «реальные» вещи. Иногда они попадают в связанные категории или подтипы. (Те, кто знаком с объектноориентированным программированием, распознают здесь наследование.) К примеру, виртуальный класс транспортных средств Vehicle может стать основой для классов аэропланов Airplane, автомобилей Automobile, кораблей Ship и т. д. Чтобы еще больше все усложнить, оба класса Airplane и Automobile вполне могут содержать коллекции экземпляров класса колес Wheel. Все становится «интересным», когда появляется сущность, которой нужен внешний ключ (FK), указывающий более чем на одну ссылочную таблицу.
Проблема в том, что первичный ключ (PK) может быть распределен по нескольким таблицам. С этим связаны два вопроса: целостности сущностей и ссылочной целостности. В DRI целостность сущностей обеспечивается ограничениями первичного ключа PRIMARY KEY, как ссылочная целостность поддерживается ограничениями внешнего ключа FOREIGN KEY. Однако эта опрятная категоризация отпадает, когда первичный ключ распростерт по нескольким таблицам. (Я посвятил несколько статей вопросам горизонтального секционирования. Идея в том, чтобы разбить большую логическую таблицу на несколько меньших физических с одинаковым набором столбцов в каждой, распределяя строки в соответствии с алгоритмом секционирования. Пользователи попрежнему смогут обращаться к ней как к единой «таблице», только теперь она станет секционированным представлением.)
В первой части статьи интеграция CLR позиционировалась как программирование на более высоком уровне по сравнению с TSQL, средним слоем и расширенными хранимыми процедурами (XP). Здесь мы рассмотрим набор задач и моделей программирования, с которыми часто сталкиваются разработчики, а также покажем, как использовать (а в некоторых случаях не использовать) CLR для решения этих задач.
(Возврат на основную страницу)