Благодаря стандартам межкомпонентного взаимодействия (об этом позже) все эти фрагменты кода комбинируются друг с другом независимо от аппаратного, программного обеспечения, операционных систем, сетей, компиляторов, языков программирования, различных средств организации запросов и формирования отчетов и динамически изменяются при манипулировании объектами без потери работоспособности. Спорные моменты технологии. Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но, когда дело доходит до практической разработки приложений на разных ООСУБД, проявляется множество отличий в реализации поддержки трех характеристик: • Целостность; • Масштабируемость; • Отказоустойчивость. Отметим, что ООБД не требуют многих из тех внутренних функций и механизмов, которые столь привычны и необходимы в реляционных БД. Например, при небольшом числе пользователей, длинных транзакциях и незначительной загрузке сервера объектные СУБД не нуждаются в поддержке сложных механизмов резервного копирования/восстановления (исторически сложилось так, что первые ООБД проектировались для поддержки небольших рабочих групп – порядка десяти человек – и не были приспособлены для обслуживания сотен пользователей). Тем не менее технология БД определенно созрела для крупных проектов. Для иллюстрации первой категории рассмотрим механизм кэширования объектов. Большинство объектных СУБД помещают код приложения непосредственно в то же адресное пространство, где работает сама СУБД. Благодаря этому достигается повышение производительности часто в 10 100 раз по сравнению с раздельными адресными пространствами. Но при такой модели объект с ошибкой может повредить объекты и разрушить базу данных. Существуют два подхода к организации реакции СУБД для предотвращения потери данных. Большинство систем передают приложению указатели на объекты, и рано или поздно такие указатели обязательно становятся неверными. Так, они всегда неправильны после перехода объекта к другому пользователю (например, после перемещения на другой сервер)