Классика баз данных - статьи
Резюме - часть 2
Хотя это может сильно шокировать администраторов баз данных, но во все более сервис-ориентированном мире, в котором воздерживаются от применения идеи непосредственного доступа к данным и взамен этого требуют, чтобы весь доступ к данным происходил через сервисные шлюзы, инкапсулируя механизм хранения данных от надоедливых глаз, становится совершенно реальным позволить разработчикам хранить данные в той форме, в которой их проще использовать именно им, а не DBA.
3. Отображение вручную. Разработчики просто соглашаются с тем, что проблема не настолько сложна, чтобы нельзя было ее решить вручную, и пишут прямой код для доступа к реляционным базам данных, обеспечивающий доступ к кортежам и позволяющий сохранять в базе данных данные объектов. Во многих случаях этот код может быть автоматически сгенерирован некоторым инструментальным средством на основе анализа метаданных базы данных, частично устраняя тем самым основу для критики этого подхода («слишком много кода нужно написать и сопровождать»).
4. Принятие ограничений ОР-отображения. Разработчики просто соглашаются с тем, что нет способа эффективно и просто решить проблему объектно-реляционного несоответствия и используют ОР-отображение для решения 85% проблемы (или 50%, или 95% в зависимости от ситуации), а в тех случаях, когда ОР-отображение может само породить проблемы, используют SQL и «примитивные» средства доступа в реляционным базам данных (такие как JDBC или ADO.NET). Однако у этого подхода имеется собственный риск, поскольку разработчики, использующие ОР-отображение, должны быть осведомлены о любом виде кэширования, производимом в используемом решении ОР-отображения, поскольку «примитивные» средства доступа к реляционной базе данных, очевидно, не будут использовать возможности этого кэширования.
5. Интеграция реляционных понятий с языками. Разработчики просто соглашаются с тем, что имеется проблема, которую следует решать на уровне языка, а не библиотеки или «оболочки».
