(Возврат на основную страницу)

Содержание номера за Февраль 2009 год

SQL Server

Февраль 2009
№ 2 (98)

Editorial

Фил Фактор

Как правильно оскорблять участников форума

Programming

Алекс Козак

SQL-техники проведения операций над матрицами

Адам Мэкэник

Практикум. Компонент Service Broker: фундаментальные основы

DB Design & Warehousing

Род Колледж

Определение рабочей нагрузки ввода-вывода

Сьюзен Сейлс Харкингс Определение зависимостей объекта перед изменением структуры схемы SQL Server

Как правильно оскорблять участников форума

Нужно ли оскорблять участников форумов, новостных групп или онлайновых дискуссий? На первый взгляд, вопрос звучит глупо и ответом на него должно быть «нет». Это неправильный подход, даже в ситуации, если ваш визави слишком далеко, чтобы потребовать сатисфакции. Однако иногда потребность высказать кому-нибудь все, что вы думаете, просто непреодолима.

Большинство людей в форумах проявляют потрясающее терпение при общении с себе подобными. Возможно это связано с тем, что они осознают, что никто не без греха, и может сам оказаться в глупом положении. Большинство сообщений в форумах пишется второпях. Те из нас, кто отвечают на много запросов, пишут ответы в «свободную минутку». Вот сейчас, когда я пишу это письмо, я приканчиваю свой обед (состоящий из банана с кофе). У меня полно работы, в результате торопливость может привести к не очень гладкому тексту сообщения и фразам, написанным под влиянием момента. Мы все ошибаемся. Мы не полируем текст наших сообщений. В результате, наши сообщения вызывают скептическое отношение и смущают читающих.

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

Что же делать в таком случае?

Проблемы

Если мне туда, я не начал бы отсюда

Первая проблема — вы можете неправильно понять другую сторону. Частая ошибка, когда вы думаете, что просьба о помощи звучит совершенно по­идиотски. Первым порывом бывает предположение, что вопрошающий не продумал алгоритм бизнес­ процесса с последующим отметающим «так чего же вы, собственно, пытаетесь достичь?» или подобным контрвопросом. Обычно вы правы, но иногда обнаруживается, что задачу поставил упертый начальник, который платит им зарплату. Другой вариант — получение в наследство и сопровождение безумной базы данных, которую каким­то немыслимым образом вывели в промышленную эксплуатацию. Может иногда в такого рода переписке и проскакивает разумная идея, но вы слишком заняты, чтобы ее заметить.

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

Языковый империализм

По сути своей SQL сообщество очень интернационально. Оно вынуждено пользоваться английским как «языком технологии», также как латынь была академическим языком триста лет назад. Для большинства из нас это нелегко. Если отчетливо видно, что английский не является родным для участника форума, а вы используете в ответе сленг или сложную метафору, ваш ответ легко неверно понять. Многие выражения, употребленные под влиянием момента могут оказаться чрезвычайно оскорбительными или унизительными для человека другой культуры, особенно, если мы говорим о шотландцах.

Мораль: высмеивание качества языка участника форума совершенно недопустимо. Если вы чувствуете, что готовы на такой поступок и английский для вас родной, попробуйте для разнообразия выучить древнегреческий. Это не просто.

Искусство браниться

Третья проблема в попытках оскорбить другого — умение ругаться, это искусство, подобное балету. И также как в балете, попытка сделать что­то без должного умения выглядит глупо.

Мораль: Марк Твен, Дороти Паркер или Оберон Во (Mark Twain, Dorothy Parker, Auberon Waugh) довели умение бранится до совершенства. Сомневаюсь, что вы достигли таких же высот, так что лучше не пытайтесь.

Высмеивание новичков

Привычка высмеивать новичков, наезды за то что они не усвоили этикета форума обычно приводит к тому что сам «шутник» выглядит глупо, кроме того, такое отношение может заставить людей покинуть форум.

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

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

Предложение

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

Мне кажется, что ответ пришел ко мне в то время, когда я работал для известного консультанта педиатра в больнице. Ему досталась деликатная работа писать письма докторам, которые направляли к нему пациентов. Часто приходилось писать о неверно поставленных диагнозах, потратили впустую время, необоснованно заставили страдать пациента или даже ускорили его кончину. В частных беседах он был способен излить бездну гнева и яда на головы опасно некомпетентных докторов. В письмах же он был сама вежливость и никогда не скупился на комплименты, а любой критицизм был богато заправлен толстым слоем лести.

Я был молод и горяч и в итоге спросил его почему письма полны неискренней сладости. Я просто не мог этого понять.

«Никто не способен сопротивляться вежливости и лести», — был ответ. «Собственно говоря, я не знаю верхнего предела лести, который способен потребить человек. Если вы хвалите и поощряете человека, которого поучаете, тогда любой упрек воспринимается легче. Всегда есть способ выразить горькую правду о способностях или подходах того или иного человека таким образом, чтобы защитить его самолюбие и в результате ваши коррективы будут восприняты более охотно. При попытке публично объявить о чьей­то глупости все что вы получите, это обиженное сопротивление».

Я настоятельно рекомендую использовать этот подход при написании сообщений в форумах. Когда мы чувствуем настоятельную потребность дать кому­то по мозгам, нужно так построить фразу, чтобы поощрить оппонента двигаться в правильном направлении и он не чувствовал бы себя униженным. Дополнительно вы получаете возможность управлять гневом и недовольством.

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

Освоив это тонкое искусство, вы обнаружите, что жизнь на форуме гораздо менее напряженна и дает больше пользы, а те, кто «знает», и так поймут, что за вашими словами таится подчас иной смысл.

Табл. 1

SQL-техники проведения операций над матрицами

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

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

Практикум. Компонент Service Broker: фундаментальные основы

Серия Workbench задумывалась так, чтобы статьи загружались в SQL Server Management Studio, прочитывались и выполнялись. Чтобы воспользоваться этим наилучшим образом, мы предложили бы испытать описываемые вещи, поэкспериментировать и в общем случае использовать их еще и как отправную точку по какому-то аспекту
SQL Server. Фактический исходный код размещен в загружаемом файле с фрагментом текста в начале статьи. Поскольку компонент Service broker — это весьма важный вводный курс, мы посвятим ему серию из трех практикумов.

Введение в SQL Service Broker

SQL Service Broker (SSB) — это мощная инфраструктура асинхронного управления очередями и обмена сообщениями, доступная во всех изданиях SQL Server 2005. Он предоставляет инструментарий для работы с широким спектром задач, начиная с простой организации очередности рабочей нагрузки и заканчивая развитой маршрутизацией сообщений между удаленными серверами.

SSB в SQL Server — это смена парадигмы; новый и улучшенный способ решения целого множества сложных задач. Но пока SSB все еще широко не применяется. Происходит ли это вследствие временных ограничений, поставленных перед разработчиками, которым есть чем заняться, вместо того чтобы изучать очередную новинку, или кажущейся сложности получения необходимых навыков, я не уверен. Но что я знаю точно, SSB невероятно полезен, и на самом деле, не так уж и сложен для освоения.

Несмотря на то что SSB довольно легко изучать, это, тем не менее, относительно большая и сложная тема, ведь с его помощью вы можете делать изрядное количество разнообразных вещей. Поэтому я разбил этот практикум на серию из трех частей. В этой первой части мы рассмотрим основы: типы объектов Service Broker, то, как их создавать, а также то, как организовывать простейшие очереди. К концу этого практикума у вас будет прочный фундамент для создания элементарных асинхронных служб, не говоря уже о том, что и для продолжения освоения этой серии.

Итак, давайте уже начнем. Broker ждет!

Определение рабочей нагрузки ввода-вывода

Чтобы выяснить, какая именно система хранения и какой объем дискового пространства идеальны с точки зрения требований конкретного приложения, важно понимать, какого типа и в каком объеме данное приложение будет пороздать операции ввода/вывода. В центре внимания этой статьи — различные типы ввода­вывода, характеристики, которые используются для классификации рабочей нагрузки, а также методы, применяемые для измерения и вычисления значений параметров, характеризующих ввод­вывод.

OLTP против OLAP/DSS

Когда необходимо классифицировать ввод­вывод, используют два основных понятия: OLTP (оперативная обработка транзакций — OnLine Transaction Processing) и OLAP (оперативная аналитическая обработка данных — Online Analytical Processing). Примером OLTP приложения является база данных, где хранятся данные, поступающие от  кассовых терминалов, для которого, как правило, характерны в основном простые, короткие транзакции, выполняемые большим числом пользователей. Такие транзакции  формируют операции ввода/вывода, называемые произвольиными (random I/O), когда физические диски ради того, чтобы выполнить операции чтения и записи, некоторую долю времени затрачивают на поиск данных, хранящихся на диске в нескольких разных областях.

В противоположность этому база данных OLAP или база данных DSS (система обеспечения принятия решений — Decision Support System) — это такая БД, в которой хранятся данные, обеспечивающих подготовку отчетов. Для таких приложений характерно не столь большое количество пользователей. Кроме того, подобные приложения генерируют запросы с результатами значительно большего объема и, как следствие этого, формируют последовательный ввод­вывод (sequential I/O), когда физические  диски затрачивают время в основном на сканирование диапазона данных, сгруппированных в одной и той же области на диске. Активность баз данных OLTP отличается от активности баз данных OLAP значительно большей долей операций чтения.

Важно заметить, что даже для классических приложений OLTP, вроде систем обслуживания кассовых терминалов, такие действия, как резервное копирование и проверки целостности базы данных, будут формировать еще и последовательный ввод­вывод в больших объемах. В целях классификации рабочей нагрузки мы будем учитывать только структуру основных операций ввода­вывода. Как мы увидим чуть позже, различия между последовательным и произвольным вводом­выводом — это важный аспект с точки зрения проектирования системы хранения данных.

Определение зависимостей объекта перед изменением структуры схемы SQL Server

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

Изменения никогда не бывают простыми. Даже небольшое изменение одного объекта может иметь для пользователей значительные последствия. К примеру, вы можете полагать, что удаление устаревшей таблицы целесообразно, но только лишь до тех пор, пока представление или отчет не перестанут работать. К тому времени, когда произойдет ошибка, вы можете не вспомнить, что удалили таблицу двумя месяцами ранее. Ваши пользователи будут недовольны, а вы потратите лишнее время, диагностируя проблему. Поэтому вам следует всегда производить доскональную оценку последствий перед осуществлением изменений, пусть даже небольших. Хорошая новость состоит в том, что получение списка зависимостей объекта — задача не столь трудная, как может казаться. Вы можете применить инструментарий управления SQL Server с графическим интерфейсом или получит ту же информацию посредством набора команд T­SQL.

(Возврат на основную страницу)