(Возврат на основную страницу)
Шелли Долл (Shelley Doll)
Если соответствие стандарту SQL — важный
момент, на который обращают внимание многие компании, выбирая реляционную СУБД,
то почему производители БД не должны
строго придерживаться этого стандарта?
Преимущества, которые дают нестандартные функции, достаются ценой снижения качества и потерей возможности портирования данных, что выгодно только одной стороне в отношениях производителя и потребителя. В этой статье рассматриваются причины ослабления поддержки стандарта ANSI/SQL и обсуждается состоятельность самого стандарта.
Для чего нужен стандарт?
Технологические стандарты важны по ряду причин, важнейшая из которых в том, что покупатель уверен в работоспособности продукта. Не правда ли, здорово, когда вы точно знаете, что ваша СУБД и СУБД ваших партнеров по бизнесу совместимы и не подведут в нужный момент? А как вам такая роскошь, когда можно выбрать РСУБД из-за ее стабильности, скорости и эффективности использования системных ресурсов, а не потому, что она поддерживает представления и транзакции, а ее конкурент — нет?
Использование стандарта дает и другие преимущества. Например, он позволяет сторонним производителям создавать инструменты и утилиты, совместимые с любым продуктом на рынке, а не с одной-единственной платформой. Аналогично, сертификация на соответствие стандарту существенно расширяет объем ресурсов, доступных производителю. Сертификация продукта гарантирует качество его функциональности, в отличие от совместимых, но не сертифицированных решений, в которых создана лишь видимость соответствия требованиям стандарта.
Все эти преимущества смогла бы обеспечить программа сертификации, но, к сожалению, нет соответствующего административного органа, следящего за соответствием стандарту SQL.
Кто здесь главный?
Более 10 лет Национальный институт стандартов и технологий США (National Institute of Standards and Technology, NIST), находящийся в ведении министерства торговли, предлагал тестировать РСУБД на соответствие стандарту. Однако 6 лет назад NIST прекратил следить за соответствием стандарту ANSI/SQL, поскольку эту деятельность сочли неэффективной и, по большей части, игнорируемой из-за отсутствия соответствующих механизмов отчетности.
По сей день большинство производителей заявляют о совместимости своих продуктов со стандартом SQL-92, названного по году выпуска — 1992. Однако на самом деле текущим стандартом является SQL-99. За прекращением контроля со стороны NIST последовал выход спецификации стандарта, которая была слишком широкой, и, как следствие, жутко дорогой, поэтому только ведущие производители СУБД могли выпускать совместимые с ней продукты. Два указанных фактора сильнее всего стимулировали отклонения от стандарта, все дальше уводившие потребителей по пути управления данными с помощью нестандартных решений, то есть случилось именно то, от чего был призван защитить стандарт ANSI.
Возникает вопрос: можно ли продолжать называть стандартом то, что от него осталось?
Единообразие — мать заурядности?
Разные производители БД в различной степени во-площали в своих продуктах требования ANSI/SQL, чтобы повысить их конкурентоспособность и удо-влетворить желания потребителей. Однако эти продукты все же могут считаться совместимыми с ANSI/SQL. В сущности, продукт является совместимым, если он удовлетворяет трем условиям:
Для примера я приведу ниже ряд отклонений из PL/SQL — диалекта SQL, используемого в Oracle, которые были приняты большинством.
Вот расширения языка PL/SQL, помеченные флагами:
Я надеялась привести аналогичный список и для Transact-SQL, языка запросов MS SQL Server, но так и не смогла найти никакой документации, касающейся специфических вопросов совместимости с ANSI/SQL (что неудивительно). Чтобы узнать, совместима ли со стандартом функция, которую вы применяете в своей БД, включите вывод предупреждающих сообщений при помощи параметра «set fipsflagger».
Этот пример должен показать, что, несмотря на утверждения производителей о том, что параметры их СУБД не выходят за рамки стандарта ANSI, нельзя просто так, не позаботившись об интеграции, взять и поменять одну БД на другую даже на уровне прикладного программирования.
Итак, стандарт потерял свой смысл; некому следить за соответствием, стало быть, нет истинной совместимости. Характеристика «ANSI/SQL-совместимый» теперь производит впечатление лишь на дилетантов и пригодна только для рекламы, она по-настоящему не связана ни с использованием БД, ни с разработкой приложений.
Что делать?
После того как в 1996 г. NIST закрыл программу по стандартизации управления данными, не осталось ни агентств по сертификации, ни каких-либо других механизмов, проверяющий производителей БД на совместимость со стандартом ANSI/SQL. Требования сообщества и престиж — вот все, что осталось на защите интересов платежеспособного клиента, а производители предпочитают функциональность совместимости, как будто никакого стандарта нет и в помине.
Необходимо ввести систему, следящую за соответствием стандарту прежде, чем миф о «стандарте SQL» опустится до уровня рекомендации и неполная совместимость станет стандартом de facto.
Дэниел Гэллахер (Daniel Gallagher)
При создании даже простейших кубов разработчика подстерегают подводные камни. Я обнаружил, что основная проблема — это качество исходных данных. Если они «чистые», то создать куб — пара пустяков. Вторая по величине проблема — не что иное как нерациональная конструкция кубов.
Вот список некоторых подводных камней, подстерегающих вас при создании кубов OLAP:
Роберт Марда (Robert Marda)
В этой статье рассмотрено несколько способов управления результирующим набором статического запроса SQL при помощи переменных, которым присваивают различные значения.
Описанные здесь методики помогут избежать использования динамического SQL, в то же время обеспечивая возможность изменения результирующего набора путем присваивания значений различным переменным. Некоторые из показанных здесь запросов менее оптимизированы по сравнению с обработкой каждого значения переменной или каждого необходимого изменения при помощи отдельных запросов. Зато они помогают избежать проблем с безопасностью, с которыми вы непременно столкнетесь при использовании динамического SQL, и отказаться от создания множества хранимых процедур. Кое-что из показанного здесь, например использование оператора CASE после ключевого слова ON в конструкции JOIN, не имеет большого практического значения и приводится лишь для демонстрации гибкости статического SQL.
Большей частью своей гибкости статический SQL обязан оператору CASE. Я не собираюсь рассказывать про все способы использования этого оператора, поскольку в большинстве своем они освещены в статье Нила Бойла (Neil Boyle) «Полезные приемы с использованием оператора CASE» (см. стр. 9), а здесь будет показано, как модифицировать результирующий набор, не прибегая к динамическому SQL.
Нил Бойл (Neil Boyle)
Оператор CASE — очень гибкий инструмент. Здесь описана лишь малая часть приемов с его использованием.
Александр Чигрик (Alexander Chigrik)
о недокументированных системных таблицах SQL Server 2000.
Эти таблицы, большинство из которых хранится в БД master (исключением являются только системные таблицы sysfiles1, sysproperties и sysfulltextnotify, которые есть в каждой БД), используются некоторыми системными хранимыми процедурами.
Рэнди Дайесс (Randy Dyess)
Эта статья продолжает серию публикаций, посвященных хранимым процедурам и освоенным мной методам работы. При переходе на новое место или работе над новым проектом они помогут вам создать и изучить новую рабочую среду.
Брэд МакГехи (Brad M. McGehee)
Однажды мне пришлось провести большую часть выходных за работой, обновляя кластер под управлением SQL Server 7.0 до SQL Server 2000.
К счастью, довольно сложная операция обновления прошла без сучка и задоринки. А сложной эту операцию делала база с данными в 31 Гб для планирования и управления ресурсами предприятия, которую обслуживал кластер. Эта база использовалась круглосуточно, и незапланированный простой был попросту неприемлем. Поэтому после завершения преобразования и проверки БД я вздохнул с облегчением.
В течение всей следующей недели я безотрывно следил за кластером, пытаясь найти любые аномалии, но так ничего и не обнаружил. В пятницу, перед тем как отправится домой на честно заслуженный отдых (поскольку мне пришлось проработать все прошлые выходные), я еще раз все проверил, и БД работала просто замечательно, преобразование завершилось полным успехом.
Или нет? Итак, в понедельник я возвращаюсь на работу, свежий и отдохнувший. Один из моих ежедневных ритуалов, которые я выполняю, как только зайду в комнату, — проверка кластера: как он работает, успешно ли функционировали задания по обслуживанию и т. д. в течение выходных. Прежде всего я проверил, успешно ли завершилось полное резервное копирование, которое выполняется еженощно. На первый взгляд, все было в порядке, но одна деталь бросилась мне в глаза: размер файла резервной копии был 20 Гб вместо обычных 31.
(Возврат на основную страницу)