(Возврат на основную страницу)
Администраторы БД! Опасайтесь xml!
Крейг С. Муллинс (Craig S. Mullins), BMC Software
За последнее время о XML сказано невероятное
количество слов. Этот язык является одной
из наиболее рекламируемых и наименее волнующих относительно новых технологий.
Если вы верите всему, что пишут, то XML появился, чтобы уничтожать драконов,
прыгать с небоскребов и позволить вашей бабушке самой писать приложения для
обработки заказов. Что за ерунда! Уверен, XML может
быть использован в качестве формата для обмена данных. Теги помогают делать
данные
до некоторой степени самодокументируемыми. Но он не является универсальным
ответом на все вопросы и представляет опасность для здоровья вашей БД!
Что такое XML?
XML означает eXtensible Markup Language. Подобно HTML, XML происходит из SGML (Standard Generalized Markup Language). Фактически, и HTML, и XML являются подмножествами SGML. HTML использует теги для описания того, как данные будут представлены на странице. XML использует теги для того, чтобы описать (до некоторой степени), что представляют собою данные. Это полезно, но не является достоверным описанием данных. Некоторые люди говорят, что XML подобен метаданным, но они, видимо, просто не знают, что такое метаданные.
Итак, XML унаследовал ключевое преимущество SGML — самоописание, одновременно избежав сложности развитого SGML. XML позволяет пользователям самим определять теги, после чего эти теги именуют элементы данных в XML-документах.
Несложный синтаксис XML упрощает машинную обработку и в тоже время делает его понятным для человека. Давайте использовать HTML в качестве метафоры, помогающей нам разобраться в XML. HTML использует теги для описания внешнего вида данных на странице. Например, <b>текст</b> будет определять, что данные «текст» должны появиться в жирном начертании. XML использует теги для документирования самих данных, а не их внешнего представления. Поэтому <LastName>Муллинс< /LastName> говорит, что «Муллинс» — это фамилия. Пока все идет хорошо…
Опасение и неприятие
Что же здесь пугает? XML выглядит как безобидный компактный язык, помогающий определять данные таким образом, чтобы они становились проще для понимания при их передаче. А ведь каждый передает массу данных, не так ли? Итак, прежде всего, XML может оказаться не самой лучшей техникой для поддержки данных, если вы заинтересованы в скорости и производительности передачи. Загромождая данные всеми этими тегами, вы можете более чем в два раза увеличить размер файлов данных, пересылаемых по сети. А чем больше файл, тем больше время его передачи.
Но, по моему скромному мнению, это не самое большое беспокойство для администраторов БД. Дело в том, что эти XML-документы пытаются проложить собственный путь в наших БД. А это уже проблема. Почему? Для этого есть много причин, но наибольший протест у меня вызывает специальные возможности, которые этот язык может предоставить пользователям, не являющимся администраторами БД.
Существует два основных подхода к хранению XML-данных в БД SQL:
1. Разбиение XML-документа на части с помощью
чтения тегов и хранение каждого элемента, от-
меченного тегами, в качестве отдельного столбца в одной или нескольких
таблицах.
2. Сохранение целого XML-документа в качестве
текстового поля или большого символьного
объекта (CLOB).
Первый подход легче для администрирования, но сложнее для внедрения. Кроме того, он требует, чтобы кто-либо (например администратор БД) отобразил каждый из элементов, отмеченных тегами, в соответствующий столбец, уже существующий в таблице. Если все будет проделано должным образом, то в результате, по меньшей мере, мы получим управляемую и удобную в использовании БД.
Второй подход, боюсь, популярнее. В этом случае весь XML-документ сохраняется как большой «ком» в огромном столбце, в качестве типа данных для которого определены text, varchar или CLOB, в зависимости от используемой СУБД. При этом вам придется работать с тем, что может быть полезно только для программ, способных анализировать XML, читать теги и «понимать» данные, сваленные в «ком». Более того, каждый раз, когда XML-программист захочет добавить туда еще больше данных, ничто не помешает ему это сделать. Достаточно добавить теги в этот XML-документ и затем «затолкать» его в БД. И снова эти данные не могут быть использованы теми, у кого нет анализирующих программ. Поэтому БД будет хранить информацию, которую иначе как «огромный ком текстовых данных» и определить-то нельзя. Есть тут кто-нибудь, кто на самом деле видит в этом прогресс?
При этом подходе БД становится просто местом хранения XML-документов. Запросы к подобной БД не дадут никакого преимущества, пока вы не поймете, как проходить иерархический XML-документ. Метаданные в системном каталоге не будут иметь особого применения, поскольку они только сообщат вам, что «здесь мы имеем огромный текстовый ком». И ничего не скажут обо всех этих тегах — и это называют полезной информацией!
Кроме того, XML предлагает слабый контроль над типами данных и длинами. Так, вы можете создать тег, называемый <AccountBalance>, в XML DTD и затем создать XML-документ, включающий в себя нечто похожее на <AccountBalance>Fred</AccountBalance>. Не знаю, как вы, но я не хочу, чтобы мой остаток на счете назывался «Fred».
Итак, то, что мы получаем, используя этот подход, — это огромное текстовое поле, куда разработчики по своему желанию могут произвольно добавлять или удалять элементы данных, и механизм хранения с минимальным контролем целостности типов данных и длины. Но постойте, есть и еще кое-что: это огромное текстовое поле оказывается абсолютно бесполезным до тех пор, пока вы не научитесь анализировать XML или не будете использовать инструмент, понимающий XML.
Все вышесказанное наталкивает на третий подход. Сегодня это наихудший подход — трудно поверить, не так ли? XML-документы хранятся в новом типе СУБД, называемом XML DBMS. Этот новый тип СУБД управляет и читает XML как XML, не разбивая его на части. Другими словами, XML используется в качестве механизма хранения. Это, безусловно, будет шагом назад к временам иерархических СУБД со всеми потенциальными ошибками, присущими иерархиям. Стоит ли попадать в эту ловушку?
Заключение
Прежде чем примкнуть к движению сторонников XML, удостоверьтесь, что вы отдаете себе отчет в том, что вы делаете. XML не искоренит терроризм и не сделает мир безопаснее. Он не является универсальным ответом. Используйте его, если вам необходимо передать данные. Но, если это возможно, держите его подальше от ваших БД.
Байя Павлиашвили (Baya Pavliashvili)
Эта статья может представлять интерес для разработчиков, а также администраторов БД. мы изучим встроенные функции для получения информации о свойствах SQL Server, конфигурации, глобальных переменных и метаданных для системных и пользовательских БД. Мы не будем обсуждать каждую из поддерживаемых функций, а рассмотрим только наиболее полезные.
Пожалуйста, имейте
ввиду, что граница между системными, системностатистическими, конфигурационными
функциями и функциями метаданных достаточно условна. Справочная система SQL
Server, как и Object Browser (доступный в Query Analyzer), группирует функции в
упомянутые выше категории.
И хотя вы могли бы предположить, что функции DB_ NAME() и APP_NAME() принадлежат
к одной категории, первой из них посчастливилось быть функцией метаданных, а
второй — системной функцией. Мы будем следовать классификации, принятой в Query
Analyzer.
Другим нюансом, о котором стоит знать, является то обстоятельство, что встроенные функции имеют очень взыскательный синтаксис. Он может потребовать использования круглых скобок даже если они не принимают никаких параметров.
Джон Пол Кук (John Paul Cook)
Microsoft .NET Framework
предлагает улучшенную производительность в подключении хранимых процедур через
ADO.NET по сравнению с ADO. Классы ADO.NET имеют множество перегруженных
методов, поэтому очень важно в достаточной мере понимать синтаксис, чтобы
«выжать»
максимум из вашего кода.
Хотя в центре внимания этой статьи находятся хранимые процедуры SQL Server, показанные технические приемы также работают с Oracle и другими БД, соответствующими стандарту OLE DB.
Крис Кемпстер (Chris Kempster)
Одной из многих основных задач администратора БД является управление контролем над изменениями. Эта статья обсуждает процессы, используемые мною день за днем, и следует за циклом изменения в разработке, проверяемой затем в реальной эксплуатации.
В статье рассматриваются следующие темы:
формализация процесса;
управление сценариями;
уровни доступа разработчиков в критических средах программирования;
возвращение в эксплуатацию с изменениями;
управление специальными изменениями — «заплатками» (hot fix).
(Возврат на основную страницу)