Конфликт «схема-владелец»
В обсуждениях подходов отображения наследования и ассоциаций всплывает одна распространенная ошибка. По сути дела, во многих инструментальных средствах объектно-реляционного отображения предполагается, что схема базы данных – это нечто, что можно определить в соответствии со методами, помогающими оптимизировать выполнение запросов от этих средств к реляционным данным. Но в действительности схема базы данных часто не находится под непосредственным контролем разработчиков, ей владеет некоторая другая группа служащих компании, обычно группа администрирования баз данных (DBA). Кто отвечает за проектирование базы данных и за принятие решений о допустимости изменения ее схемы?
Во многих случаях разработчики начинают новый проект с «чистой доски», с пустой реляционной базой данных, схему которой они могут определить так, как пожелают. Но вскоре после завершения проекта (иногда даже раньше, по политическим причинам или из-за «войны за территорию») становится очевидным, что владение разработчиками схемой является, в лучшем случае, временным. Различные отделы начинают требовать отчеты о базе данных, на DBA возлагается ответственность за производительность базы данных, что дает им повод требовать проведение «рефакторинга» и денормализации данных, и другие группы разработчиков могут начать интересоваться возможностью использования данных, сохраняемых в базе данных. Вскоре схема должна быть «заморожена», что потенциально создает барьер для рефакторинга объектной модели (см. ниже обсуждение «проблемы сопряжения»). Кроме того, эти другие группы часто будут рассчитывать увидеть реляционную модель, определенную в реляционных терминах, а не в той, которая поддерживает полностью ортогональную форму персистентности. Например, трудности будет представлять столбец-дискриминатор, используемый для решения проблемы отображения наследования, и, вероятно, он окажется почти бесполезным для реляционных генераторов отчетов, таких как Crystal Reports. Это состояние дел, скорее всего, окажется неприемлемым, если только разработчики не пожелают вручную составлять отчеты (и конструировать пользовательские интерфейсы, писать код для печати и т.д.).
(Честно говоря, эта проблема является не столько технической, сколько политической, но, независимо от источника и способа решения, она является серьезной проблемой. И она представляет препятствие для достижения решения ОР-отображения.)
