Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

Решайте проблемы просто
Всегда есть два способа решения любой проблемы: простой и сложный. Но люди по-
чему-то всегда выбирают сложный. Это не всегда делается намеренно, чаще — по не-
знанию. Разработчики просто не предполагают, что СУБД может делать "это". Я же
предполагаю, что СУБД может делать все, и пишу что-то собственноручно, только если
оказывается, что этого она не делает.

---

Разработка успешных приложений для Oracle
Например, меня часто спрашивают: "Как сделать, чтобы пользователь мог подклю-
читься к базе данных только один раз?". (Есть еще сотня примеров, которые я мог бы
здесь привести в качестве иллюстрации.) Наверное, это требование многих приложений;
правда, в моей практике разработки такие приложения не встречались — я не вижу вес-
кой причины для того, чтобы ограничивать пользователей подобным образом. Однако
другим разработчикам это нужно, и они обычно придумывают сложное решение. На-
пример, создают пакетное задание, выполняемое операционной системой и просматри-
вающее представление V$SESSION, а затем произвольно прекращающее сеансы пользо-
вателей, подключившихся к базе данных более одного раза. Или создают собственные
таблицы, в которые приложение вставляет строку при регистрации пользователя и уда-
ляет ее по завершении работы. Подобная реализация неизбежно приводит к многочис-
ленным обращениям в службу поддержки, поскольку если приложение завершает рабо-
ту нештатно, строка из этой таблицы не удаляется. Я видел еще много "творческих"
способов добиться этого, но ни один из них не был таким простым:
ops$tkyte@0RA8I.W0RLD> create profile one_session limit sessions_per_user 1;
Profile created.
ops$[e-mail]> alter user scott profile one_session;
User altered.
ops$[e-mail]> alter system set resource_limit=true;
System altered.
Вот и все. Теперь любой пользователь с профилем ONE_SESSION может подклю-
читься только один раз. Простота этого решения обычно приводит разработчиков в во-
сторг и вызывает запоздалые сожаления. Потратьте время на ознакомление с имеющи-
мися средствами и их возможностями — это позволит сэкономить много времени и сил
при разработке.
Тот же принцип "делай проще" применяется и на более высоком, архитектурном уров-
не. Я рекомендую подумать дважды, прежде чем браться за сложные реализации. Чем
больше "движущихся частей" в системе, тем больше компонентов, которые могут рабо-
тать неверно, а при использовании сложной архитектуры определить, что именно яв-
ляется причиной ошибки, будет непросто. Может быть, использование "надцатиуров-
невой" архитектуры — это действительно "круто", но лишено смысла, если в простой
хранимой процедуре можно сделать то же самое, но лучше, быстрее и с использовани-
ем меньших ресурсов.
Я участвовал в разработке приложения, продолжающейся более года. Это было Web-
приложение, используемое в масштабе компании. Клиент на базе HTML и с использо-
ванием технологии JSP динамически получал страницы с сервера промежуточного уров-
ня, который взаимодействовал с CORBA-объектами, в свою очередь, обращавшимися к
СУБД. CORBA-объекты должны были поддерживать "состояние" и подключаться к СУБД
для организации сеанса. В ходе тестирования этой системы оказалось, что потребуется
много серверов приложений и очень мощная машина для работы СУБД, чтобы поддер-
живать 10000, как предполагалось, одновременно работающих пользователей. Более того,
иногда возникала проблема нестабильности, связанная со сложностью взаимодействия