Тема номера: «Сделано в России»

Виктор Абрамов
(v.abramov@rtcomm.ru),
системный администратор в
ИТ-дирекции компании
РТКомм.РУ (Москва)

Лучшее - враг хорошего

Источник: журнал "Открытые системы", №6б 2004, http://www.osp.ru/os/2004/06/069.htm

Когда я прочитал статью “Remedy для ITIL” (Открытые системы, 2004, №1), у меня возник ряд сомнений в целесообразности предлагаемого авторами использования ARS Remedy на предприятиях, где уже развернута СУБД Oracle. Конечно, если заказчику подходит готовое апробированное решение Remedy, то отговаривать я его не буду, непонятно только, зачем использовать в этом случае Oracle в качестве лишь хранилища данных.

……

[От редакции “Oracle Magazine/Русское Издание”: В распоряжении редакции имеется более полный текст этой статьи нашего постоянного автора и научного редактора OM/RE Виктора Абрамова. Мы предлагаем вниманию наших читателей первоначальный вариант, поскольку:

Поэтому, если кого-то из прочитавших эту достаточно задиристую статью, она подвигнет на потребность высказать свое мнение, наболевшее и выстраданное, интернет-журнал “Oracle Magazine/Русское Издание” может предоставить свои страницы для дискуссии по этой очень важной и актуальной теме.

С уважением,
Анатолий Бачин,
главный редактор OM/RE]

Виктор Абрамов
(v.abramov@rtcomm.ru)
разработчик ПО для Oracle

Почему я не советую использовать ARS Remedy, если Вы в качестве СУБД уже выбрали ORACLE

Если фирме подходит готовое апробированное решение Remedy, ради Бога, можно брать. Непонятно только, зачем использовать в этом случае Oracle “в качестве всего лишь хранилища данных”, к тому же без учета архитектуры СУБД.

Попробую объяснить свою позицию.

Обычно Заказчик вновь разрабатываемой (или “дорабатываемой”, что, как правило, мало отличается от разработки с нуля) системы слабо представляет себе, КАК должна разрабатываться информационная система и КАКИМ ТРЕБОВАНИЯМ она должна отвечать. Слова типа “четвертая нормальная форма”, “ER-модель” или “Data
Structure Diagramm” для него ровным счетом ничего не значат. Для него - главное, чтобы в срок была сдана работоспособная система. Для Разработчика - главное, чтобы она была работоспособна на момент сдачи в эксплуатацию. Понимание того, что уже разработанная система требует все новых и новых вложений, доработки следуют непрерывно, одна заплатка ставится поверх другой, получение данных из этой системы наталкивается на какие-то необъяснимые препятствия, а интеграция с другими системами становится постоянной головной болью, приходит слишком поздно. Кроме всего этого вдруг оказывается, что по мере накопления данных в системе она начинает “тормозить”, просто потому, что приложение не учитывает особенностей архитектуры конкретной СУБД.

Для того, чтобы не оказаться в такой ситуации, нужно, по меньшей мере, ознакомиться с элементарными принципами разработки информационных систем и выбрать средство разработки, учитывающее архитектуру СУБД и использующее предлагаемые этой самой СУБД средства поддержки ограничений целостности. Кроме этого следует учесть, что Oracle, если вы выбрали именно ее, - достаточно сложная система, включающая в себя не только средства хранения плоских таблиц, но и средства поддержки целостности базы данных (последовательности, триггеры, ограничения целостности), средства разработки серверных приложений такие как язык построения запросов SQL, процедурный язык PL/SQL и язык Java, средства для работы с internet- и intranet- технологиями и многое другое.

Клиент, покупая СУБД Oracle, за все перечисленные возможности заплатил деньги. И я не понимаю, почему он должен заплатить еще столько же, чтобы от всего этого отказаться. Хотя лицензионная политика Oracle и Remedy отличаются, можно утверждать, что в случае разработки приложения на Remedy заказчику придется заплатить как минимум двойную цену - за сервер Oracle и за каждое рабочее место ARS Remedy независимо от того, идет ли речь о Fixed-лицензиях Remedy, закрепляемых за конкретными пользователями, и/или о Floating-лицензиях.

Вы можете представить себя в такой ситуации: купив дорогой музыкальный центр за $1000, вы несете его в мастерскую, где за такую же сумму от него оторвут MP3-плеер вместе с проигрывателем компакт-дисков, отломят ручку регулировки тембра и выкусят из колонок высокочастотные динамики, потому что Вы собираетесь использовать этот центр для прослушивания радиостанции “Маяк” по утрам - и больше ни для чего? Вот и я тоже не могу...

Конечно, лицензия по чтению в Remedy ничего не стоит, однако компанию, где несколько тысяч человек только потребляют информацию, которую вносят в базу данных всего трое несчастных сотрудников, думаю, найти не удастся.  Зато случаев, когда пользователь открыл приложение и занял, таким образом, Floating-лицензию на целый день, - хоть отбавляй. Прикажете звонить пользователю, дабы поинтересоваться, не хочет ли он освободить ее?

Утверждение, что дополнительные расходы с лихвой окупаются скоростью разработки, вообще говоря, спорно. Дело в том, что “по правилам” разработка информационной системы начинается с фазы стратегии, затем следует фаза предварительного анализа, сбор информации, после чего начинается анализ требований, в ходе которого разрабатывается ER-диаграмма и диаграмма процессов, а затем на основе ER-диаграммы строится диаграмма структуры данных (Oracle Designer включает для этого специальную утилиту). При этом модель данных должна соответствовать, по меньшей мере, четвертой нормальной форме (в двух стандартных формах ARS Remedy - User и Group - нарушается даже первая нормальная форма, то есть список кодов групп, в которые входит пользователь, хранится в одном поле, через разделитель). Следствием нарушения 1NF может быть необходимость доработки приложения после изменения некоторых данных. Иногда после анализа полученной ER-модели проводится ее сознательная денормализация с целью ускорения работы приложения. Затем создается физическая модель данных, и только после этого можно приступать к разработке собственно приложения. Понятно, что на практике разработка ИС часто начинается с середины, некоторые этапы остаются недостаточно проработанными, но к моменту начала разработки собственно приложения модель данных должна быть готова. 

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

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

Конечно, скорость разработки приложения может несколько возрасти за счет отказа команды разработчиков от этапа проектирования модели данных, однако результат такой разработки, как правило, будет ужасен, а разобраться в модели данных, по меньшей мере, затруднительно. И, конечно, при таком подходе вполне естественно звучат утверждения разработчика Remedy о том, что структура данных не должна волновать заказчика системы, поскольку это внутреннее дело Remedy, а СУБД используется ”всего лишь как хранилище данных”!

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

Сергей Королев в своем ответе на мою реплику (http://www.osp.ru/os/2004/01/039.htm) называет в качестве главного преимущества Remedy ее мультибазовую ориентацию (“какое хранилище данных используется серверами ARS для приложений безразлично. Может быть MS SQL, Oracle, Sybase, DB2, Informix, т.е. любая современная SQL база”). Я бы назвал это отсутствием какой бы то ни было ориентации, поскольку такой подход заведомо означает отказ от учета архитектуры используемой СУБД.

“Мультибазовая ориентация”, может быть, хороша для разработчиков приложений. Они могут портировать их на любые СУБД и продавать клиентам, пока еще не подозревающим, насколько бездарно эти приложения будут использовать ресурсы их нового мощного вычислительного комплекса. Кроме этого, клиент, выбравший конкретную СУБД, вряд ли от нее откажется, так что для него “мультибазовая ориентация” отнюдь не должна быть каким-то преимуществом.

Я приведу цитату из книги Т.Кайта “Oracle для профессионалов”, одного из самых авторитетных программистов-профессионалов в сфере Oracle, мнение которого я разделяю: “Странная идея о том, что разработчик приложения баз данных должен быть огражден от СУБД, чрезвычайно живуча. Многие почему-то считают, что разработчикам не следует тратить время на изучение СУБД ...... СУБД - это инструмент, а неправильное применение любого инструмента может привести к катастрофе. Вы будете щипцами колоть орехи так же, как молотком? Можно, конечно, и так, но это неправильное использование инструмента, и результат вас не порадует. Аналогичные результаты будут при игнорировании особенностей используемой СУБД” (Том Кайт “Oracle для профессионалов” в 2-х т., изд. “Диасофт”, Киев, 2003)

Невозможно разработать эффективное приложение, не учитывающее особенностей конкретной СУБД. Так, например, всего лишь отказ от использования связываемых переменных очень сильно перегружает SQL Area и в итоге буквально на порядок снижает производительность Oracle. Мощная система вынуждена тратить огромные ресурсы на постоянный жесткий разбор SQL-операторов, отличающихся друг от друга всего лишь одним значением константы. “Если бы мне пришлось писать книгу о том, как создавать немасштабируемые приложения Oracle, первая и единственная ее глава называлась бы “Не используйте связываемые переменные”. Это - основная причина
проблем, связанных с производительностью, и основная помеха масштабируемости... Если надо замедлить работу приложения Oracle вплоть до полного останова - откажитесь от их использования” (Том Кайт “Oracle для профессионалов”)

Remedy не использует не только такие возможности Oracle, как встроенный процедурный язык PL/SQL, триггеры базы данных и механизм ограничений целостности. Remedy не использует даже формат даты. Вместо этого дата хранится в Oracle в числовом формате (количество секунд, прошедших с 01.01.1970). Уже только одно это затрудняет доступ к хранящимся в базе данным иными средствами, чем предлагает Remedy, а предлагает он всего два способа построения отчетов - это своя внутренняя система отчетов (слишком бедная, чтобы широко ее использовать) и Crystal Reports, работающий через Remedy ODBC, причем с рядом ограничений. А ведь одна из важнейших целей автоматизация бизнес-процессов - это возможность оперативно использовать накапливаемые с помощью внедряемого
приложения данные для принятия управленческих решений. Это значит, что руководству может потребоваться разработка некоторого количества нестандартных отчетов, причем в весьма сжатые сроки, что можно сделать только силами собственного подразделения IT. Следовательно, структура данных приложения должна быть хорошо продумана, а данные - легко доступны. Oracle - действительно открытая среда, однако ARS Remedy закрывает ее почти со всех сторон, и это не может не раздражать.

Ну и, напоследок, еще раз перечислю возможности и особенности Oracle, которые,
по моим наблюдениям, не использует ARS Remedy:

• не используется встроенный процедурный язык Oracle PL/SQL;
• не используется формат даты Oracle;
• не используются встроенные средства поддержки целостности данных (первичные и внешние ключи, а также триггеры базы данных);
• не используются связываемые переменные в SQL-запросах, причем разработчик лишен возможности как-то влиять на это;
• не используются последовательности (sequence) - вместо этого ARS хранит следующие значения ключей в таблице;
• не используется возможность Oracle добавлять и удалять столбцы из существующих таблиц;
• при генерации таблиц не используется возможность задания индивидуальных параметров   хранения таблиц.

Справедливости ради надо сказать, что Remedy не одинока в своем нежелании учитывать архитектурные особенности используемой СУБД. Гарантированно же используют архитектуру СУБД только “родные” для них средства разработки. Так, в случае Oracle можно выбрать в качестве средства разработки Oracle Application Server Forms and Reports Services 10g (9.0.4.0.0), а в качестве средства проектирования базы данных - Oracle Designer (http://otn.oracle.com/software/products/ids/index.html).