АригатоТрадиционно при реализации проектов я вводил поддержку разных СУБД, а не только MySQL

каких например? postgresql,oracle,sqlite,firebird,mongodb...
даже поддержку ВСЕХ популярных сделать огромная проблема, а еще в рамках одной БД есть разлиция на уровне версий, типов таблиц и т.д.
такие вещи по хорошему надо закладывать изначально. прогнозировать рост проекта и под это дело выбирать БД. а в случае взрывной популярности когда выбранная бд не будет справляться даже после всех тюнингов и апгрейдов сервака(или кластера) - простой сменой на другую все равно ничего не выиграете. для хайлоада совсем другие требования, придется перепроектировать скорее всего почти все а не только уровень БД. а может и перейти на nosql. а заранее такие вещи предусмотреть все равно никто никогда не сможет

АригатоК примеру, в MySQL хочется использовать триггеры, но имея абстракцию в виде описанных выше классов, такое сделать проблематично.

не совсем понятно. повесили вы триггер на удаление, например. он сам и будет срабатывать при delete. чем вам помешает ваша абстракция? это же происходит на уровне самой бд.

АригатоСмысл в потенциальной поддержки, а не в том, какие классы уже реализованы. Т.е. при необходимости можно реализовать класс для поддержки любой другой СУБД, при этом не внося никаких изменений в код самого проекта.
начнем с того что реализовать настолько универсальную абстракцию чтоб она могла работать с ЛЮБОЙ из существующих БД - почти невозможно. так как по сложности это превзойдет сам проект где эта абстракция будет использоваться. поэтому если есть именно цель - сделать поддержку кучи БД - то придется это делать, иначе это лишнее

АригатоНу так триггер надо еще создать, а как написать универсальный метод для создания триггера? Конечно, можно извратиться, но это уже слишком.
таблицы, представления, триггеры... - создаются обычно на уровне design time а не в real time. следовательно в вашем приложении БД-абстракция и не должна уметь это делать универсально. к тому же это делается только раз. и это можно прописать просто нативным кодом и выполнить через query.
считаю что проблема притянута за уши

считаю что распаляться на поддержку всего зоопарка БД нет смысла. если это не самоцель.

само приложение же не абстрактно. оно призвано решать определенные задачи. под них и нужно подобрать БД и другие компоненты. и с ними работать.
чем универсальнее попытаетесь сделать - тем больше потратите времени и тем тормознее будет работать. это очевидно.