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

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

Обычно заказчик вновь разрабатываемой системы слабо представляет себе, как должна создаваться информационная система и каким системным требованиям она должна отвечать. Заклинания типа «четвертая нормальная форма», «ER-модель» или «Data Structure Diagramm» для него ровным счетом ничего не значат — главное, чтобы в срок была сдана работоспособная система. А в результате, новая система требует все новых и новых вложений, причем доработки следуют непрерывно, одна заплатка ставится поверх другой, получение данных наталкивается на необъяснимые препятствия, а интеграция с другими системами становится постоянной головной болью. Вдобавок, по мере накопления данных, работа системы замедляется — приложение не учитывает особенностей архитектуры СУБД.

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

Remedy не использует даже внутренний формат даты Oracle — дата хранится как количество секунд, прошедших с 01.01.1970, и уже только одно это затрудняет доступ. При этом в Remedy предлагается только два способа построения отчетов: достаточно бедная своя внутренняя и Crystal Reports, работающая с рядом ограничений через Remedy ODBC. А ведь одна из важнейших целей автоматизации бизнес-процессов — возможность оперативного использования накапливаемых данных для принятия управленческих решений, что требует разработки нестандартных отчетов силами самого заказчика.

Разработка информационной системы должна начинаться с фазы стратегии, затем следует фаза предварительного анализа, сбор информации, после чего начинается анализ требований, в ходе которого разрабатывается ER-диаграмма и диаграмма процессов, а затем на основе ER-диаграммы строится диаграмма структуры данных (Oracle Designer включает для этого специальную утилиту). Затем создается физическая модель данных, и только после этого можно приступать к разработке приложения. Понятно, что на практике разработка ИС часто начинается с середины, некоторые этапы остаются недостаточно проработанными, но к моменту начала разработки собственно приложения, модель данных должна быть готова. В ARS Remedy сделано с точностью до наоборот. Первичной является форма, к разработке которой приступают до генерации модели данных. Таблицы создаются конструктором форм по мере разработки этих форм. При модификациях форм, связанных с изменением структуры данных, конструктор форм ARS Remedy создает новые таблицы и переносит в них данные из старых, которые затем удаляются. Даже при объемах всего в несколько гигабайт перенос модифицированных форм на промышленный сервер становится проблематичен.

Конечно, скорость разработки приложения может несколько возрасти за счет отказа команды разработчиков от этапа проектирования модели данных, однако результат, как правило, будет ужасен.

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

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

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