(Возврат на основную страницу)
В этой статье Дон Петерсон анализирует, почему ему… не нравится XML! Здесь есть несколько интересных утверждений, и, если вы раньше не задумывались, что XML значит для вас как для администратора баз данных, то эта статья заслуживает внимания.
Когда у меня появились первые наброски этой статьи, XML был одним из самых модных терминов. Он вел всех нас в абсолютно новый мир, где системы будут легко интегрироваться силами этих маленьких магических тэгов… Только представьте, как было бы замечательно хранить все данные в формате XML! Системы управления базами данных на основе XML, несомненно, станут следующим эволюционным шагом, который наконец уничтожит impedance mismatch (несоответствие объектной и реляционной моделей). Каждый уважающий себя поставщик программного обеспечения просто должен будет использовать XML везде! Все, что преподносилось как неоспоримые преимущества этого решения, вызвало у меня подозрения. Я решил разобраться в причинах такого ажиотажа. После многих месяцев исследований и тестирования я пришел к выводу, что XML не только не является решением любой глобальной проблемы управления или обмена данными, но что это достаточно глупый ответ на все неправильные вопросы! Более того, стало ясно, что XML фактически является гигантским прыжком в неверном направлении, увековеченным теми, кто не знает или не понимает основ управления данными.
Изначально статья была внутренним документом, который я отправил менеджерам в попытке урезонить программистов, которые вставляли XML в большие поля varchar в базе данных. Мои усилия были в основном успешными. Политика компании изменилась, позволяя теперь программистам использовать XML только для коммуникации, но не для хранения в базе данных. К сожалению, многие из наших поставщиков изменили свои продукты для использования XML, и во всех без исключения случаях мы столкнулись с проблемами — от увеличившегося объема для хранения данных до сильно раздувшихся файлов журнала и абсолютно неэффективных запросов. По предложению моего менеджера я отредактировал документ и отослал его в SQL Server Central. Я никогда не думал, что он будет опубликован, поскольку он противоречил мнению большинства и был, как сказали бы некоторые, подстрекательским. К моему удивлению, я получил много содержательных и поддерживающих мое мнение комментариев.
Сейчас XML уже не является модным термином, но, к сожалению, он крепко укоренился почти в каждом подходе к управлению данными. Я, как и многие другие, все еще придерживаюсь глубокого убеждения, что XML не решает никаких проблем, и, если подробно изучить этот вопрос, оказывается, что XML в действительности вызывает даже больше проблем, чем может потенциально решить.
Несмотря на маркетинговые требования главных поставщиков и желание шагать в ногу со временем, было бы разумным точно проверить, какие преимущества предлагает XML, и сравнить их с затратами, прежде чем необдуманно погружаться в XML с головой.
Идея XML довольно проста: вы просто добавляете тэги в файл данных. Эти тэги иногда интерпретируются как метаданные. XML по своей сути строго иерархичен. Ниже представлены основные преимущества, которые усиленно расхваливаются:
самоописание данных;
облегчение межплатформенного совместного использования данных или «свободное соединение» приложений;
простота моделирования «неструктурированных» данных.
Самоописание данных
Идея самоописываемых данных звучит великолепно, но давайте разберемся в подробностях. Ниже представлен классический пример самоописания данных в XML:
<Product>Shirt
<Color>Red</Color>
<Size>L</Size>
<Style>Hawaiian</Style>
<InStock>Y</InStock>
</Product>
Возможный эквивалентный текстовый документ выглядит так:
Red,L,Hawaiian,Y
В отличие от простого текстового документа, документ XML можно просмотреть и определить значение каждого элемента. Но преимущество ли это? В конце концов, файлы данных будут читать не люди, а машины. Что более эффективно для машины: считывать данные или генерировать? Что лучше для ограниченной полосы пропускания сети? Файл XML занимает в 6 раз больше места, чем текстовый файл. В моих исследованиях файлы XML были в 45 раз больше, чем такие же файлы с разделителями. Изза раздутой сущности XML поставщики аппаратного обеспечения уже предлагают ускорители для компенсации этой проблемы. Что еще хуже, появляется все больше и больше нестандартных анализаторов XML, которые написаны для «оптимизации» XML, но полностью уничтожают всякую иллюзию о «совместимости». (Смотрите http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2896005,00.html.) Некоторые пытались доказать, что сжатие помогает компенсировать фактор раздутости XML. Даже без детального анализа можно убедиться, что это полный нонсенс. Если вы начинаете с файла, в 4 раза большего, чем его эквивалент, и потом сжимаете его, то вам, возможно, посчастливится уменьшить его до размера файла без XML, но что будет, если сжать этот самый файл без XML? Кроме того, данный аргумент подразумевает, что сжатие является «бесплатным». Сжатие действительно увеличивает пропускную способность и экономит дисковое пространство, но требует времени на обработку.
Облегчение коммуникации
Самодокументирующаяся сущность XML часто расценивается как помощь в коммуникации между приложениями: мы можем посмотреть на файл XML и сделать разумные предположения, так как значение данных основано на тэгах. Также формат файла может меняться, не влияя на коммуникацию, потому что он основан на тэгах, а не на расположении данных. Однако если тэги изменяются или не подходят, то коммуникация будет прервана. Запомните хотя бы сейчас, что компьютеры не умеют строить догадки.
Независимо от использования специальных средств коммуникация между системами требует соблюдения двух условий:
1. соглашение по тому, что будет отправляться (что обозначают данные);
2. соглашение по формату.
XML не меняет эти требования, и несмотря на уверения в обратном это не упрощает дело. Для эффективной коммуникации между системами с помощью текстового файла и отправитель, и получатель должны сначала согласовать, какие элементы будут отправляться (это определяется по расширению файла и означает, что значение каждого элемента уже определено) и позицию каждого атрибута в файле. При использовании XML каждый элемент должен быть определен и все соответствующие тэги должны быть согласованы заранее. Заметьте, что самих тэгов недостаточно для верного описания данных и их значения. Для этого необходимы бизнесправила, которые управляют использованием данных, пока не будет создан универсальный стандарт, который определяет соответствующий тэг для каждой возможной сущности, которая может быть описана в документе XML (см. http://www.well.com/~doctorow/metacrap.htm). То, что тэги XML расцениваются как самоописывающиеся, приводит многих к дальнейшим ошибочным предположениям, что определенные тэги будут правильно передавать точное значение данных. В лучшем случае сами тэги передают примерное значение, а этого недостаточно. В действительности было замечено, что тэги XML являются метаданными, только если вы не понимаете саму суть метаданных (см. http://www.tdan.com/i024hy01.htm).
Способ передачи данных не играет роли; усилия по правильной идентификации данных и их значения остаются теми же. Единственное отличие, привносимое XML, — это дополнительная большая нагрузка на вашу систему.
Неструктурированные данные
Сама идея неструктурированных или полуструктурированных данных — это сочетание противоположностей. Без среды, в которой данные создаются, изменяются и используются, сами данные — всего лишь тарабарщина. Изза риска избыточности данные имеют определенное значение лишь в пределах бизнесправил, в которых они создаются и изменяются. И это не преувеличение. Очень простой пример: данные '9837790099937' не поддаются расшифровке без правила, указывающего, что это верный номер определенной запчасти. Другой пример, который часто приводят сторонники XML, — это книга. Но она состоит из частей, глав, абзацев, слов и букв, и все они расставлены в определенном порядке, так что не говорите мне, что книга неструктурированна!
Опять же, какое преимущество дает XML? Никакого. Данные попрежнему должны быть смоделированы, так как их значение должно быть сохранено, но XML по своей сути иерархичен, что переносится и на данные. Было также замечено, что XML — это просто возврат к иерархическим базам данных прошлого. Проблема заключается в том, что не все данные иерархичны. Реляционная модель данных по своей сути не иерархична, но она безусловно способна сохранять существующие иерархии. Они не являются нейтральными, поэтому иерархия, которая хорошо работает в одном приложении или одном варианте просмотра данных, будет абсолютно неправильной для других случаев, разрушая независимость данных (см. http://www.geocities.com/tablizer/sets1.htm).
Именно здесь и содержится настоящая проблема. Не имеет значения, каким большим и неэффективным может быть XML для передачи данных, но он абсолютно ужасен в управлении данными. Иерархические базы данных вымерли, как динозавры, десятилетия назад, и по простой причине: они негибки, и ими очень трудно управлять.
Я могу понять, почему многие программисты, работающие с объектноориентированными структурами, любят XML. И объектноориентированные структуры, и XML иерархичны, и, если вы привыкли мыслить в терминах деревьев и наследования, то множества могут показаться вам абсолютно чуждыми. Это одна из основных трудностей объектноориентированной парадигмы, а сейчас как раз то время, когда профессионалы по управлению данными обучаются основам. Теория множеств и логика предикатов (основы реляционной модели данных) оказались лучше иерархических СУБД, основанных на теории графов. Почему же никто не вспоминает о целостности данных, когда какойнибудь программист кричит о impedance mismatch, несоответствии между объектноориентированной структурой и реляционными данными? Почему всегда автоматически подразумевается, что «ошибка» находится в области технологий баз данных? (См. http://www.geocities.com/tablizer/oopbad.htm.)
Я добиваюсь от многих команд разработчиков, чтобы они не хранили XML в базе данных как столбец varchar большой длины или text. Это превращает ее в не более чем простое хранилище XML. Конечно, это нарушает один из принципов устройства базы данных — атомарность, или, в очень свободной трактовке, — один столбец, одно значение. Как может СУБД поддерживать какуюлибо целостность в столбце, содержащем XML? Как я узнаю, что разные строки XML, хранящиеся в данной таблице, имеют какието отношения? Индексирование и оптимизация по такой схеме невозможны. (На заметку: когда эта статья была впервые опубликована, Microsoft как раз упомянула, что Yukon будет иметь тип данных XML. Сейчас SQL Server 2005 практически готов, и в нем планируется встроенная в базу данных поддержка XML. Независимо от того, насколько хорошо Microsoft сможет реализовать сжатие и индексирование на типе данных XML, он все равно подходит только для иерархических данных и не годится для общего управления данными.)
Поставщики
Почему главные поставщики аппаратного и программного обеспечения полны такого энтузиазма по поводу XML, если он настолько плох? Ниже представлено несколько предположений.
1. Незнание. Отделы маркетинга управляют разработкой продукта и очень хотят, чтобы он содержал какойнибудь модный термин. Незнание частью общества потребителей реального положения вещей позволяет маркетологам увлечь нас разговорами.
2. Глупость. Технические «эксперты» часто неграмотны, и, так как этому нет никаких оправданий, я назову это глупостью. Я провел несколько часов на последнем SQL PASS Summit, пытаясь найти хоть когото из команды SQL Server, кто мог бы предоставить хотя бы одну хорошую причину для использования XML. К концу диалога вокруг стола собралось как минимум пять «экспертов», и никто из них не мог привести разумных аргументов. Некоторые ответы были просто шокирующими. Один из них утверждал, что самое большое преимущество XML в том, что программисты могут легко подстраивать базу данных под изменяющиеся требования, «загружая» столбцы с множеством атрибутов, чего база данных сделать не может! Здесь я понял, что зря трачу время. Через два часа я покинул их с нарастающим чувством тревоги за будущее SQL Server. Уверен, что они были рады моему уходу, так как смогли вернуться в свою фантастическую XMLнирвану. Вместо того чтобы предпринять какиелибо шаги для более глубокой реализации реляционной модели, они гоняются за своими хвостами, пытаясь внедрить неудачную идею ушедших десятилетий.
3. Жадность. Недавно я прочитал статью, превозносящую возможности XML. По мнению автора, компании полагают, что «XML улучшит их информационные возможности, но также это приведет к необходимости обновления основных систем» (http://www.dbta.com/frontpage_archives/903.html). Примечательно, что он не уточняет, как именно XML «улучшит» чьилибо возможности, кроме благосостояния поставщиков программного и аппаратного обеспечения.
Вы должны иметь в виду, что основные поставщики необязательно ставят именно ваши интересы во главу угла. Я уверен, что, когда XML признают плохой идеей, вам помогут все исправить… за дополнительную плату.
Заключение
Не поддавайтесь расплывчатым речам и притягательной рекламе. Как профессионалы по управлению данными, вы ответственны за безопасность данных вашей компании и не можете эффективно выполнять свои обязанности, не зная основ или игнорируя их. Прочитайте статьи «An Introduction to Database Management Systems» (Chris Date) и «Practical Issues in Database Management» (Fabian Pascal) и чувствуйте себя уверенно, основываясь на известных принципах управления данными. Альтернатива? Можете тратить время, пытаясь угнаться за последней причудой индустрии, отдавая деньги поставщикам и консультантам на каждом круге этой гонки.
Вы знакомы с инструкциями по установке SP3? (Если вы устанавливали SP3 в разгар кризиса Slammer, то могли пренебречь readme.) В SP3 была представлена новая опция конфигурирования сервера — межбазовые цепочки собственности CrossDatabase Ownership Chaining, и, если при установке вы не приняли варианты по умолчанию, то ваши пользователи могут лишиться доступа к некоторым хранимым процедурам и пользовательским функциям (UDF), которые применяли раньше. Заметьте, что эта опция влияет лишь на такие ситуации, при которых хранимая процедура, представление или пользовательская функция из одной базы обращается к данным из другой.
Одно из базовых правил безопасности SQL Server заключается в том, что, если однажды были предоставлены права на хранимую процедуру или представление (или пользовательскую функцию в SQL Server 2000), то вам не надо предоставлять права на какиелибо объекты, на которые имеются ссылки. Например, если создать представление, которое выбирает подмножество строк из таблицы, и затем позволить пользователям делать выборки SELECT из этого представления, то вам уже не надо разрешать доступ ко всей таблице. Другим примером является хранимая процедура, которая обновляет таблицу при определенных условиях. Вам достаточно дать пользователям право EXECUTE запускать эту хранимую процедуру и не позволять им выполнять операции обновления UPDATE в базовой таблице. Такой подход обеспечивает защищенный и управляемый доступ к данным.
Однако, начиная с SQL Server 2000 SP3, администраторы баз данных могут управлять предоставлением и запретом возможности создания цепочек собственности, простирающихся между несколькими базами. По умолчанию эта опция отключена. В общем, я сторонник предоставления администраторам более широких возможностей управления, но в этом случае специалисты Microsoft изменили настройки безопасности, которые действовали многие годы. И в результате невнимательность при установке SP3 (и, предположительно, нескольких последующих служебных пакетов SP для SQL 2000) оборачивается сломанными приложениями и огорченными пользователями.
Одной из возможностей, которую, как я слышал, просили ввести в SQL Server, является способность шифровать информацию на уровне баз данных. В SQL Server 2000 единственным вариантом было применение программных продуктов третьих фирм, поскольку не существовало встроенных средств, позволявших взять необработанные данные и сохранить их в зашифрованном виде. Однако с появлением версии SQL Server 2005 Beta 2 специалисты Microsoft ввели шифрование на уровне баз данных.
Если шифрование на уровне баз данных останется в окончательном продукте, то администраторы баз данных SQL Server смогут в списке своих сокровенных пожеланий отметить галочкой еще один пункт. В этой статье я рассмотрю, почему эта возможность настолько востребована и как она работает в версии бета 2. Я также поделюсь мыслями о том, как применять шифрование и расскажу о некоторых аспектах шифрования в SQL Server.
Пароли, уязвимые данные и то, что видеть не должны
В базах данных SQL Server принято хранить всевозможную информацию — от библиотечных списков до паролей, идентификаторов и номеров кредитных карт. Аудиторы обычно бросают косые взгляды, когда биты такой уязвимой информации, как пароли, идентификаторы и номера кредитных карт доступны просмотру в незашифрованном виде, даже если увидеть их может лишь администратор баз данных. Пароли становятся большой проблемой, поскольку возникает тенденция их многократного использования людьми. Поэтому очень вероятно, что для входа в приложение некоторый пользователь применяет тот же пароль, что и для своего входа в Windows. Это та самая ситуация, когда карандаш проверяющего начинает яростно скрести бумагу. Другой тип данных, которые стоило бы зашифровать, — это суммы заработной платы в базе данных отдела кадров. В ежедневно выполняемых администраторами баз данных операциях незашифрованные данные не требуются, поэтому нет смысла их показывать. Если возможности шифрования из версии бета 2 перейдут в готовый продукт, у нас будет собственное встроенное решение для обоих описанных типов сценариев и еще для множества других ситуаций, с которыми приходится сталкиваться. Некоторые возможности бетаверсии весьма обширны, другие же крайне просты и быстро выполняются.
Возможность программно управлять сервером баз данных появилась в SQL Server с введением распределенных управляющих объектов Distributed Management Objects (DMO) в SQL Server 6.0. С каждой новой версией эти объекты заметно совершенствовались, но всегда сохранялась совместимость с прежними версиями. Разработчиков смущало, что одновременно существовали объекты Server и Server2, а какие методы следовало к ним применять, было не совсем понятно.
Теперь же в SQL Server 2005 от объектов DMO отказались в пользу SMO. Новые объекты SQL Server Management Objects не просто заменили распределенные управляющие объекты, но и усовершенствовали функциональные возможности, позволяющие программировать в приложениях управление сервером. Поскольку в управленческой среде происходит множество изменений, эти объекты все еще совместимы с версиями SQL Server 7.0 и SQL Server 2000.
Все превратилось в .NET
Опираясь на .NET, как на общий каркас для всех технологий, оболочка SMO внедряется в виде сборки .NET. Точно так же, как вы можете организовать доступ к CLR из SQL Server, вы можете воспользоваться и всеми функциональными возможностями DMO в своих приложениях .NET. Пространство имен SMO описывается как Microsoft/SqlServer.Smo, которое по умолчанию размещается в каталоге c:\program files\Microsoft SQL Server\90\SDK\Assemblies. Оно устанавливается вместе с клиентскими инструментами и требует также установки библиотеки периода исполнения CLR.
Одно из отличий от DMO в том, что объекты репликации не входят в состав комплекта объектов SMO. Взамен появились объекты управления репликацией — Replication Management Objects (RMO), которые существуют самостоятельно. Они позволяют управлять всеми ее аспектами, включая новую подготовку параллельных мгновенных снимков, инициализацию подписки из резервной копии, подписку на данные из других баз (например, из Oracle) и т. д. Для этих объектов заведено новое пространство имен (Microsoft.SqlServer.Replication), расположенное в каталоге Microsoft.SqlServer.Rmo.dll, который является еще одной сборкой .NET. Но не отчаивайтесь — не все превратилось в .NET. Существуют COM«обертки» классов SMO, которые позволяют работать в неуправляемом окружении. Файл библиотеки SQLSMO.dll размещается вместе с другими узлами, и существует файл SQLSMO.tlb, который показывает в браузере объектов как сам SQLSMO, так и его объекты более низких уровней. Это позволяет продолжить работу SMO с VBScript и другими наследуемыми методами программирования COM.
В этой части статьи, посвященной усовершенствованиям в SQL Server 2005, обсуждаются обобщенные табличные выражения и рекурсивные запросы.
* См. Боб Бошмен, Нилс Берглунд, Дэн Салливан. Новшества TSQL в SQL Server 2005. Части 13 // SQLServer для профессионалов. 2005. № 46.
(Возврат на основную страницу)