Январь/Февраль 2004
Профессионалу администратору
Том Кайт
Корпорация Oracle
Разработка успешных приложений для СУБД Oracle
(Developing Successful Oracle Applications)
(Часть V)
Источник: журнал Oracle Magazine, раздел "Articles online only", 2001,
http://www.oracle.com/oramag/webcolumns/2001/4826_Chap01.pdf
[ От редакции "Oracle Magazine/Русское Издание":
мы заканчиваем начатую в предыдущих номерах журнала публикацию
фрагментов из первой главы "Разработка успешных приложений для СУБД Oracle"
книги Тома Кайта ("Эксперт один на один с системами
баз данных Oracle") в переводе
А.П.Соколова (РДТЕХ, Протвино):
Полностью перевод книги Т.Кайта под названием "Oracle для профессионалов.
Книга 1. Архитектура и основные особенности" выпущен издательством
"ДиаСофт", которое приобрело у изд.
Wrox Press права на перевод и публикацию книги "Expert One on One: Oracle" ,
Wrox Press, 2001, ISBN 1861004826
(
http://www.wrox.com/ACON11.asp?WROXEMPTOKEN=226473Z0ingTdnhkSEinQ3g0kU&ISBN=1861004826).
Публикация в нашем журнале отрывков из первой главы "Разработка успешных приложений для СУБД Oracle"
осуществляется по согласованию и с согласия изд."ДиаСофт".]
Глава I
- Содержание I-IV частей в предыдущих выпусках OM/RE:
- Мой подход (ссылка)
Подход к СУБД как к “черному ящику”
- Как нужно (и как нельзя) разрабатывать приложения для СУБД Oracle (ссылка)???
- Понимание архитектуры СУБД Oracle
- Не выполняйте длительные транзакции в среде многопотокового сервера
- Используйте переменные связывания
- Понимание управления конкурентным доступом
- Реализация механизма блокирования (ссылка)???
- Многоверсионность
- Независимость приложений от СУБД? (ссылка)???
- Влияние стандартов
- Функциональные возможности
- Содержание V (последней) части:
- *Простое решение проблем
- *Открытость
- *Как я заставляю СУБД работать быстрее?
- *Отношения АБД с разработчиками
- *Заключение
Разработка успешных приложений для СУБД Oracle
Простое решение проблем
Всегда существует два способа решения всего, что угодно: простой способ и трудный способ. Я неоднократно встречаю пользователей, которые выбирают трудный способ. Не всегда это делается сознательно. Чаще это происходит из-за невежества. Они даже не могли предположить, что СУБД способна сделать "это". Я, с другой стороны, считаю, что СУБД способна на все, и выбираю "трудный" способ ( причем разрабатываю его сам) только тогда, когда обнаруживаю, что СУБД чего-то сделать не может.
Например, меня часто спрашивали: "Как можно запретить конечному пользователю создание в СУБД более одного сеанса?" (я мог бы привести сотни подобных примеров). Это должно было быть требованием для обеспечения работы многих приложений, но ни одного такого приложения я не встречал: я не смог найти достаточных оснований для подобных ограничений пользователей. Однако есть желающие сделать это и выбирающие трудный способ. Например, запускают в операционной системе пакетное задание, которое просматривает таблицу V$SESSION (список сеансов и их атрибутов) и произвольно уничтожает сеансы пользователей, имеющих более одного сеанса. Альтернативно создают собственную таблицу, в которую приложения при соединении с системой базы данных вставляют строку, а при отсоединении удаляют ее. Такая реализация неизменно приводит к многочисленным обращениям в службу поддержки, так как при аварийном завершении приложения соответствующая строка никогда не будет удалена. Я видел много "творческих" способов решения такой задачи, но нет ничего проще следующего способа:
ops$tkyte@ORA8I.WORLD> create profile one_session limit sessions_per_user 1;
Profile created.
ops$tkyte@ORA8I.WORLD> alter user scott profile one_session;
User altered.
ops$tkyte@ORA8I.WORLD> alter system set resource_limit=true;
System altered.
Теперь любой пользователь, которому назначен профиль ONE_SESSION, сможет создавать только один сеанс. Когда я показываю это решение, как правило, слышу похлопывание рукой по лбу, за которым следует утверждение: "Я никогда не знал, что так можно сделать". Найдите время для ознакомления с инструментальными средствами, и это поможет сэкономить в ваших проектах массу времени и энергии.
Аргумент "сохраняйте простоту" применим и на более высоких архитектурных уровнях. Я убеждаю пользователей хорошо подумать, прежде чем принимать решение о сложных реализациях. Чем больше в вашей системе "движущихся частей", тем больше ее компонентов может выйти из строя, а точно локализовать ошибку в чрезмерно сложной архитектуре не так просто. Использование многочисленных звеньев может оказаться целесообразным, но не в том случае, когда простые хранимые процедуры могут быть лучше, быстрее и потреблять меньше ресурсов.
|
