нужно отделить мух от котлет. если, к примеру, мне нужен джейсон в запросах, то стандартизированно его просто нигде нет, запросы по любому будут затачиваться под конкретную дб. "универсальный скл" покрывает только очень простой набор вариантов, который вполне можно реализовать, но необходимо оставить возможность специализированных запросов "нэйтив скл". и если ты хочешь покрыть и специализированные запросы/синтаксис, но так, чтобы это было общим интерфейсом, то тут первым делом на ум приходит ООП. я для подобного несколько лет назад начал придумывать интерфейс, но не закончил.
По-моему решение не в ООП-чего-то-там, а скореев парсинге SQL в AST-дерево и преобразованиях между разными вариантами сделать однои то же в разных базах: подменой функций, формированием разных конструктов на выходе.
В ORM-ООП-варианте всё равно на нижнем уровне придётся делать разный SQL под разные варианты движков, при этом ООП-специфика ограничивает scope запросов, а т.ч. сложные аналитические запросы с объединениями можно будет клеить только уже в коде приложения.
