Классика баз данных - статьи
Кроме того, поддержка инфраструктуры баз
Кроме того, поддержка инфраструктуры баз данных обходится недешево, и она, как все прочее, автоматически не удешевляется. Наконец, фактором расходов может быть само программное обеспечение баз данных. Большая часть его функциональных средств не требуется конкретному приложению, так что клиентам приходится платить за ненужные им возможности. Эта ситуация несколько улучшается при использовании систем баз данных с открытыми кодами, таких как PostgreSQL and MySQL; но, тем не менее, многие организации все еще замкнуты на использовании дорогостоящих коммерческих систем баз данных.
Классическая трехзвенная архитектура систем баз данных и способ ее сегодняшней реализации не отвечают требованиям предсказуемости. При наличии многих клиентов, одновременно производящих доступ к базе данных, практически невозможно понять, что происходит на уровне базы данных. Кроме того, как отмечалось выше, масштабируемость в этой архитектуре ограничивается двумя верхними уровнями.
Еще одной целью разработки, не поддерживаемой должным образом в традиционных архитектурах систем данных, является гибкость. Причина этого состоит в том, что в настоящее время на всех трех уровнях используются разные технологии. В нижнем звене применяются SQL и реляционная модель; в среднем звене – объектно-ориентированный подход; в верхнем же звене – XML/HTML и клиентские скрипты. В результате изменение функциональности (т.е. настройка) должно производиться во всех трех звеньях с использованием трех разных технологий. Такие настройки трудно реализовывать и тестировать.
Полезно напомнить два принципа разработки приложений баз данных в классической трехзвенной архитектуре. Первым принципом является контроль. В нижнем звене СУБД контролирует все аппаратные ресурсы и весь доступ к данным. Второй принцип обычно называется принципом "передачи запросов" ("query shipping") [6]. Этот принцип означает, что как можно больше функций выталкивается в нижнее звено за счет использования хранимых процедур или других средств современных систем баз данных (например, новых типов данных или новых возможностей запросов).С положительной стороны, оба эти принципа помогают достичь наиболее важных целей разработки традиционных систем баз данных: согласованности и производительности. Передача запросов также стимулируется бизнес-моделью большинства поставщиков СУБД: лицензии на использование новых СУБД будут покупаться только в тех случаях, когда в этих СУБД обеспечивается больше функциональных возможностей. С отрицательной стороны, эти два принципа разработки превращают СУБД в монолитных монстров, которые становятся все больше и больше и никогда не уменьшаются. Эта тенденция наносит вред предсказуемости, гибкости и масштабируемости. Кроме того, эти два принципа делают системы IT дорогостоящими, поскольку для поддержки нагрузки в нижнем звене требуется дорогостоящая аппаратура, и сама сложность современных СУБД обходится совсем не даром. Поэтому неудивительно, что в архитектуре, представляемой в следующем подразделе, предлагаются в точности противоположные принципы разработки.
