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