Какие требования у вас к интерфейсу класса, работающего с базой данных? На сколько для вас удобно широкое абстрагирование от запросов? Интересно узнать, что вас более всего привлекает в работе с базой данных через класс-оболочку?

Что имеется в виду под "абстрагированием от запросов"? ORM?

Я видел, как некоторые пишут класс с малым количеством методов, довольствуются методом query, в который передают строку запроса и парой методов получения данных, вернутых сервером. Если посмотреть иходники joomla, то видно что они на много шире абстрагируются от запросов к базе данных, например отдельно ставят limit и offset и так далее...
надеюсь, доступно))

Нравиться CodeIgniter'овский activeRecord, простые запросы можно написать в очень наглядном виде, и быть уверенным в том что точно всё заэкранированно.
Как только запрос становиться более громадный, приходиться руками писать. Опять же используя placeholder'ы. Это хорошее правило которое гарантирует что не допустишь иньекции.

Хотя сейчас понимаю что от activeRecord стоило вообще отказаться - лучше использовать mysqli, имхо.

Добавлено через 1 минуту и 36 секунд
думаю, что больше пишу руками потому что не сталкивался с переносом на другой язык sql

Это не абстрагирование, это конструктор. Смысла в нем лично я не вижу. Обычно при его создании руководствуются туманными представлениями о прекрасном будущем и соображениями экономии кода. В итоге получается сильно наоборот. 
Абстрагирование - это, скорее, ORM.

Ипатьев, да, возможно я выбрал не то слово, но все-таки?

Для формирования запросов к базе я использую в своих проектах три подхода:
1. Конструктор запросов. Легкий, для простейших выборок. Грубо говоря, выглядит вроде:

2. Подготовку (prepare) запросов с плейсхолдерами. В основном для UPDATE/DELETE/INSERT. Пример:

3. Громоздкие запросы пишу руками.

Противникам конструкторов могу сказать, что я не фанат этой идеологии, но порой так гораздо удобнее. Особенно, когда речь идет о добавлении фильтров в произвольном порядке на определенных условиях (пользователем, к примеру). Тем более, что в своей модели я всегда закладываю анализатор и бенчмарк запросов, который при девелоперской разработке можно посмотреть и поправить при необходимости.

Добавлено через 3 минуты и 8 секунд
Вообще, помимо работы с формированием SQL'я, используется множество подходов при работе с результатом выборки. Я использую обертку для каждого типа выборки, которая предоставляет необходимый интерфейс для работы с данными в моем приложении.

Устраивают самописный конструктор + для сложных запросов рукаими. юзаю mysqli

Была необходимость переноса проекта на MSSQL решилось заменой файла запросов к БД переписанную для новой реализации.

rMaveric, если не сложно, какой интерфейс предоставляет ваш самописный конструктор?
IZ@TOP, поскольку с конструкторами запросов я никогда не сталкивался, не могли бы вы чуток подробнее рассказать о них, как используются, как примерно работают?

 Zend_Db.

До использования сабжа юзал самопальный, так вот даже названия методов и их использование совпали. Из этого я понял, что мой код очень даже на уровне))
Так вот я перешел на Zernd_Db: много драйверов для разных СУБД, отличная документация, качественный код, поддержка. И очень активнор развивается.

Поэтому писать что-то свое, когда есть Zend_Db...

Zend_Db_Table не юзаю, ибо мой скаффолдинг переписывать лень - все проверено и работает.
Тебя же это не ограничит, поэтому юзай и его.

По поводу ORM, то простые вещии мне проще сделать на недоорм(своя реализация на ZF), а сложные SQL-запросами.

Не могу не согласиться. Если ты не знаешь за что взяться и как писать - используй то, что предлагают тебе создатели языка.

Как работают конструкторы рассказывать бессмысленно, это понятно из названия. Используя ООП подход вы просто задаете какие части запроса и как должны быть составлены, далее конструктор просто собирает все данные в исходный SQL и выполняет.