Ключи к базе данных

Джо Селко (Joe Celko)

Microsoft вовсю рекламирует применение CLR в следующей версии SQL Server 2005. Например: «Используя интеграцию с com­mon language runtime (CLR), вы сможете программировать ваши хранимые процедуры, функции и триггеры на любом из языков, поддерживающих .Net Framework» (msdn.microsoft.com/sql/default.aspx?pull=/library/en­us/dnsql90/html/sql_ovyukondev.asp).

Я выбираю COBOL, так как 78% программ во всем мире написано на этом языке. Для него нет версии CLR? Хорошо, попробуем старый PL/I­код, который все еще кое­где используется. Нечестно? Будь по­вашему: я выбираю ADA и стану работать по военным контрактам. Я хочу подчеркнуть следующее: «на любом из языков» подразумевает, что вы будете писать на одном из языков Microsoft. А что делать, если вы любите Java, а не C#?

Продолжим цитирование. «Многие задачи, которые было неудобно или затруднительно программировать на Transact­SQL, лучше реализовать средствами управляемого кода...» С этим я согласен. Но это не те задачи, которые следует программировать в рамках базы данных. Мы в свое время шутили, что SQL можно расшифровать как «Scarcely Qualifies as a Language» (Вряд ли Можно Назвать Языком), так как он не поддерживает прямые операции ввода­вывода и не способен форматировать результаты выполнения. Его математика ограничена в силу того, что он не предназначен для вычислений. Он не выполняет текстовый поиск, обработку списков, графика ему также недоступна. Единственная задача SQL — извлечение данных и манипулирование ими. Точка.

Добавляя новую и новую функциональность, вы получаете неудобоваримую кашу, которая хорошо не делает ничего. Как сказал Антуан де Сент­Экзюпери, «совершенство достигается не тогда, когда нечего добавить, а когда нечего отнять».

Меняем плохое на ужасное!

Следующая цитата от Microsoft поистине интересна: «Вы сможете лучше применить знания и опыт, ранее приобретенные при написании кода».

Вот вам и профессиональный рост в версии Mic­rosoft. «Огг не любит лук и стрелы. Огг не будет учиться стрелять. Огг прибьет добычу камнем. Как всегда!» Неважно, что на старый опыт не всегда можно положиться в новой ситуации. Вернемся к моему неандертальцу: «Огг прибьет ящерицу камнем, Огг шарахнет саблезубого тигра булыжником и съест кошку на обед». Видите потенциальную проблему? Для неандертальца с булыжником все выглядит, как ящерица.

Вас приглашают превратить СУБД в файловую систему и по­прежнему писать код на языке третьего поколения, вместо того чтобы обратиться к декларативному программированию. Если у вас проблемы с декларативным программированием, например, при написании кода ограничений в DDL, возможно, вам стоит попросить о помощи и все­таки научиться. Подобные средства доступа к структуре БД в руках программиста, не имеющего надлежащей подготовки, — не очень хорошая идея.

Есть еще один способ использования CLR для приведения организации к коллапсу — смешение нескольких языков в рамках СУБД.

Вам приходилось сравнивать реализацию функ­ции MOD() в разных языках программирования? Порядок предпочтений операторов? Когда поднимается флаг EOF? При достижении последней строки файла или при выходе за границы последней строки? (Кстати, вы знаете, как это делает стандартный курсор, реализованный на SQL?) Вы строите циклы с проверкой в начале или в конце? Как ваш язык обрабатывает трехзначную логику в конструкциях IF­THEN­ELSE или SWITCH?

Справедливости ради отметим, что по ссылке http://msdn.microsoft.com/sql/default.aspx?pull=/library/en­us/dnsql90/html/sqlclrguidance.asp вы сможете найти большую статью «Using CLR Integration in SQL Server 2005», в которой представлена позиция Microsoft в отношении использования CLR в рамках SQL Server 2005.

Говорите на Microsoft?

Когда языки располагались за рамками СУБД, у нас были стандарты, определенные ANSI/ISO, которые определяли интерфейсы. Но языки были вне СУБД и не вызывали срабатывания триггеров или исполнения хранимых процедур, написанных на множестве разных языков. Теперь все это в прошлом. Код представляет собой такую смесь, что вы никогда не выйдете из-под опеки Microsoft и не сможете взаимодействовать с иным источником данных.

Этот подход — повторение старых ошибок. Уничтожение послойной архитектуры — фундаментально неверный подход. Он угрожает целостности данных и возвращает нас в худшие времена файловых операций при обработке данных.

Несомненно, маленький Джонни, получивший сертификат администратора БД, считает себя профессионалом и способен пролезть внутрь СУБД, но может ли кто-то ответить мне, что за преимущества получит его фирма?