Автор: © Дмитрий Волков
Введение
В данной статье я сделал краткий обзор проблем, с которыми сталкиваются разработчики, создающие проекты в среде Oracle.
Коротко рассматриваются особенности ведения проектов и подбора команды разработчиков.
Делается краткий обзор средств проектирования и разработки приложений, проводится их сравнительный анализ. Приводятся наиболее типичные допускаемые ошибки при проектировании БД и разработке приложений.
Выбор БД и ОС
Выбор БД часто оказывается камнем преткновения в начале проекта. Если выбор ОС часто диктуется аппаратным обеспечением, которое или уже есть, или на которое есть деньги, то выбор БД порождает споров не меньше, чем какой автомобиль лучше.
В чем же здесь дело? Наверно в том, что в начале проекта мы слабо представляем себе все задачи, которые нам предстоит решать.
Что может помочь в выборе БД? Я бы расставил приоритеты так:
- Опыт существующей команды. Очень хорошо, если в команде уже есть опытные разработчики на Oracle. C другой стороны, здесь скрыта и проблема - если члены команды привыкли к определенной БД, знают ее сильные и слабые места, они внутренне будут сопротивляться переходу на новую платформу. И способны саботировать проект в целом.
- Следствие из предыдущего пункта. Не стоит выбирать следующую БД на порядок сложнее предыдущей. Это тоже вызовет сложности и непонимание. Так если Ваше приложение написано на плоских файлах и в команде никто никогда не слышал слова sql и транзакции не стоит переходить сразу на Oracle. Можно (и нужно взять что-то попроще). Иначе простые задачи на новой и сложной БД будут решаться неприемлемо долго. В практике также встречаются случаи, что команда не привыкшая использовать транзакции и конкурентный доступ к данным даже перейдя на Oraclе, так и продолжаем писать однопользовательскую версию системы.
- Предпочтения в использовании платформ. Так, если и разработчики и коллектив в целом предпочитают платформу Windows, и только слышали про ""этот страшный Unix" нет особенного смысла бороться с такой предвзятостью. Поверьте, что Вам и так будет с чем бороться.
Итак. Внимательно посмотрите, что говорят разработчики, и что они умеют. Не заставляйте прыгать их выше своей головы. Помните, что Oracle это сложный продукт. Документация только на БД включает в себя около 20,000 страниц!. Я помню что, когда я впервые увидел документацию на Oracle, она стояла в комнате разработчиков, занимая целую стену! Казалось невероятным прочитать все это даже за всю жизнь!
Но если Вам удалось настоять на выборе Oracle и Unix - поздравляю Вас. Ваш путь камикадзе начался!
Организация проекта
Проект
Организуя проект, Вы должны очень хорошо представлять себе сроки проекта, его бюджет и команду, которая призвана реализовать этот проект. И если обсуждение сроков и бюджета выходит за рамки данной статьи, то принципы подбора важнейших членов Вашей команды мы обязательно рассмотрим дальше.
Что касается собственно проекта, то требуйте от него только одного - чтобы он был закончен. Ничего не угнетает морально больше чем прекращенный проект.
Команда
Самым важным звеном команды, несомненно, является ее лидер - project manager. Именно от него зависит, будет ли успешным проект. Его важнейшими качествами являются возможность противостоять внешнему давлению вышестоящего руководства, умение противостоять внешнему давлению.
Но не менее важным является и его технический background. Он должен быстро, в разговоре с руководством успеть просчитать сколько времени уйдет на реализацию той или иной фичи системы. С другой стороны, поскольку он видит всю картину целиком, он должен подсказывать другому члену команды - DBA - что из возможностей БД следует использовать в той или иной части проекта.
|
Если Вам удалось застать Вашего лидера за написанием кода или перестановкой ОС на своем компьютере немедленно прогоните его. Он занимается не своим делом! А пострадать может проект в целом. |
Как правило, степень близости лидера проекта к пониманию проблем разработки прямо пропорциональна моральному климату в коллективе.
Другим важным членом команды является DBA - Database Administrator. Он гуру. Его уважают и слушают. Когда у разработчика что-то не выходит, он бежит к dba и внимательно слушает его указания. Он должен внимательно проверять все предлагаемые технические решения, выносить свой вердикт - использовать их или нет. От его работы зависит, насколько безболезненно система войдет в строй, и будет эксплуатироваться. Важно, чтобы такой администратор был в вашей команде с самого начала проекта.
В конце я бы отметил "закон бутерброда" для проектов. Итак, вы грамотно ведете проект. Ваша команда хорошо информирована и тренирована. Структура БД ясна и понятна. Система отлично выглядит и эффективно работает. Но не беспокойтесь. Всегда найдутся дополнительные фичи или параллельный проект который разрушит вашу безмятежную жизнь (Jonathan Lewis)
Средства проектирования
Использование case-средств при проектировании современных систем уже перестало казаться ненужным излишеством. И тем не менее все еще успешно игнорируется многими командами. Мне приходилось много раз видеть и слышать мнение, что написать скрипты вручную гораздо быстрее и легче.
Это преступное заблуждение. Во-первых, такой проект невозможно кому-либо продемонстрировать. Как следствие, затруднено добавление членов команды.
Во-вторых, через год, полгода написание связанных запросов начинает занимать все больше и больше времени. Никто уже не ориентируется в структуре БД.
Вот как я определяю, насколько хорошо ведется проектирование. Если в комнате разработчиков есть доска, а на стенах весят ER- диаграммы, то по крайне мере разработчики обсуждают, что они делают. У меня в комнате сейчас есть и доска и диаграммы J.
Какое средство проектирование использовать ? То, которое Вы знаете …
Я же крайне рекомендую использовать Oracle Designer. Это прекрасное средство, проверенное в огромном количестве проектов, обладающие всеми Вам необходимыми свойствами. К тому же Designer может выполнить генерацию программного кода, который вы далее сможете полностью или частично использовать дальше. Так, в проекте связанном с созданием web интерфейсов на perl и php я использовал не только генерацию собственно схемы данных, но и так называемого table API - процедурного интерфейса для обращения к данным. Это крайне удобно и экономит массу времени.
Средства разработки
Windows средства (Delphi, Power Builder, Visual C++)
К достоинствам этих средств разработки стоит отнести
- Высокое качество интерфейса
- Большое кол-во существующих компонент, библиотек и т.п.
- Высокую скорость разработки
К недостаткам
- Работа только в Windows среде
- Драйвер для связи с БД может оказаться непроизводительным или не поддерживает все возможности сервера.
- Необходимость установки на каждую клиентскую станцию run-time библиотек.
Высокая гибкость этих средств позволяет разработчику совершить и массу ошибок. Так, внезапно может оказаться, что при просмотре в grid таблицы из пары миллионов строк возможность передвинуть ползунок приводит к тому, что приложение полностью зависает. Также очень часто разработчики увлекаются универсальными формами, которые умеют "все". При этом они пытаются генерить sql код "на ходу". По этому поводу лучше смотреть главу "Список основных ошибок".
Perl/Php
Бесплатно распространяемы средства разработки, имеющие миллионы разработчиков по всему миру. Интерфейсы к БД Oracle написаны волонтерами, и достаточно производительны. Правда, как правило, они поддерживают не все возможности сервера (вернуть коллекцию или объект). Тем не менее, для создания web интерфейсов эти средства широко и успешно используются. Здесь по моему опыту разработчики стараются удержаться в рамках одного выбранного языка и напрочь отрицают использование хранимых процедур сервера. По этому поводу лучше смотреть главу "Список основных ошибок". Стоимостью наибольшей гибкости является время разработки - наибольшее среди обозреваемых средств. Это связано с отсутвием каких либо графических средств разработки для этих языков.
Java
Oracle давно и последовательно поддерживает java. Виртуальная машина уже находится в БД - вы можете создавать хранимые процедуры на java. Для создания клиентских приложений Oracle предлагает свой продукт JDeveloper. Драйвера для доступа к БД разрабатываются самим Oracle и поддерживают почти все возможности сервера. Технология jsp позволяет Вам создавать облегченный вариант вашего интерфейса. Так что если вы готовые на дополнительные накладные расходы на CPU и скорость исполнения не является для Вас критической, эта технология кажется одной из наиболее привлекательных.
Oracle средства (Forms, Reports)
Это наиболее старые средства разработки клиентских приложений предлагаемых корпорацией Oracle. Они представляют собой законченное решение для разработки приложения для доступа к данным. Честно говоря, я до сих пор уверен, что наиболее производительно создавать большие приложения именно на Oracle Forms.
К сожалению, внешний вид приложений получающихся с помощью forms- reports оставляет желать лучшего. К тому же они как правило требовательны к памяти. Что и заставляет многих разработчиков выбирать другие средства для своих проектов. А очень жаль! Соотношение качество приложения/скорость у Forms очень - очень хорошее!
Oracle средства (Portal - WebDB)
Проект WebDb был изначально написан Tom Kyte как замена тяжелому и неуклюжему Oracle Web Server и позже был включен в состав Oracle Internet Application Server как модуль mod_plsql. В дополнение к возможности писать web формы на языке pl/sql, Portal добавил огромное кол-во возможностей -
- Создавать формы, отчеты, графики прямо при помощи web-интерфейса
- Управлять доступом к этим объектам
- Создавать полноценные корпоративные порталы
Как и в случае Oracle Forms этот продукт позволяет быстро создавать грамотные приложения, но не всегда позволяет изменить внешний вид своего приложения. По сравнению с Oracle Forms, этот продукт легче осваивается, проще в эксплуатации. Плата за это - ограниченная функциональность.
Контроль версий
Это обязательный элемент любого проекта. Тут даже обсуждать нечего.
Требуется только разработать схему создания новых версий продукта, способы расстановки тегов. Также требуется разработать процедуру установки новых версий у клиентов.
Какой продукт использовать?
Я использовал при разработке на Unix платформах - связку Emacs - CVS, в Windows - PVCS. К сожалению последний является коммерческим программным обеспечением.
На данный момент Oracle позиционирует свой продукт Oracle SCM - Software Configuration Manager как средство работы с версиями, но я еще его не использовал.
Безопасностность и надежность
Наиболее часто конечно на практике встречаются случаи, когда экземпляр (instance) Oracle находиться в корпоративной сети, за firewall. Поэтому относительно немного известно атак на собсвенно сервер через интренет. Тем не менее, к наиболее распростаненным можно отнести
- Заведенные пользователи имеют пароли по умолчанию, описаные в документации
- Listener не защищен от атак (по ip адресам/подсетям)
Список наиболее вопиющих ошибок можно прочитать по адресу http://www.nextgenss.com/papers/hpoas.pdf. Не пугайтесь сразу - эти ошибки известны Oracle и они уже закрыты патчами.
С другой стороны, с ростом приложения, объемов, используемых опций сервера, возникают и непредвиденные ошибки Oracle, знаменитые ora-600. С ними приходится бороться, определять возможные пути решения, иногда не тривиального. Хороший администратор пытается не допустить возникновения таких ошибок, регулярно просматривая появляющиеся патчи и внимательно читая исправленные ошибки.
Список основных программных ошибок совершаемых при разработке
- Не использование bind переменных и как следствие неэффективное использование shared_pool, повторяющийся hard parsing запросов. Наиболее распространенная и неприятная ошибка. Все это ведет к замедлению работы приложения. Мне известен случай когда не используя bind переменных после загрузки данных (много insert без bind переменных) разработчики перегружают инстанс Oracle. Непонимание того, как работает оптимизатор, ведет к появлению мифов что "Oracle надо перегружать". Чаще всего такую ошибку можно наблюдать в приложениях, которые пытаются генерить sql предложения на лету.
- Плохое управление соединением с БД (Connection manager). Если приложение вынуждено перед каждым запросом вновь соединяться с БД это увеличивает время работы и потребляет значительные ресурсы. Чаще всего такая ошибка возникает при разработке web приложений (cgi). Такое приложение не поддается маштабированию.
- Плохое управление вводом/выводом. При проектировании физической структуры БД не уделяется внимание равномерному распределению нагрузки по физическим дискам. Так наиболее востребованные таблицы часто оказываются на одном диске и его скорость оказывается "узким местом".
- Большое кол-во рекурсивных (SYS) sql. Как правило, они появляются когда требуется управление размером объектов. Т.е. изначально обекты созданы с неверными размерами. С появление locally managed tablespace и опциями uniform size эта проблема постепенно отступает.
- Большое количество long full scan. Чаще всего это говорит или о пропущенных индексах, плохих запросах или неверном дизайне приложения.
- Использовании rule оптимизатора или использование cost based оптимизатора но без сбора статистики
- Использование нестандартных инициализационных параметров.
- При создании web приложений забывают, что следует применять перед изменением записи процедуру блокировки. Таким образом, два пользователя могут одновременно внести изменения в одну запись. Oracle рекомендует применять так называемый "Optimistic lock" механизм, который заключается в том, чтобы убедиться что за время работы с записью она не изменилась.
- Загрузка данных в БД. Для загрузки данных корпорация Oracle предлагает специальные решения. Самый старый и известный из них - sqlloader. Тем не менее, очень часто встречаются попытки грузить информацию гигабайтами предложениями insert.