Думаю, есть смысл сделать функцию query_execute не private, а public.
Это потому, что если я хочу скажем сделать
ALTER TABLE, ANALYZE, CHECK и т.п. - запросы, относящиеся к DDL, а не к DML, мне нечем воспользоваться в этом классе, а функций на все запросы такого типа не написать (вернее, если и написать, то будет громоздко, неудобно и по факту повторять то, что уже есть в MySQL - выполнять переданный запрос).
Да и запросы DML не все можно определить при помощи функций класса.
Например, я хочу сделать
INSERT .. SELECT или вложенный запрос, или UNION или JOIN или SELECT * FROM myTable USE INDEX(myIndex) и т.п. - всего и не перечислишь
- мне опять же нечего использовать и опять же всего нельзя написать в классе.
Иначе говоря, без возможности писать запрос напрямую, класс сможет выполнять лишь самые простенькие запросы, чего может быть недостаточно (лично мне было бы очень недостаточно).

Да, я уже пытался пользоваться классом в разработке, пришел к мысли, что нужно позволить пользователю писать свои запросы, убрать массивы из запросов, и т.п. Упростить, вобщем, но это была хорошая практика именно для меня, потому что я еще не особо уверенно пишу что-то. Плюс неудобно, когда функция принимает много параметров. Я, как автор, еще с грехом пополам их помню, но если этим классом будет пользоваться сторонний разработчик, то думаю, моей семье будет шибко икаться.
Так что мечта о гарантированно валидных запросах таки останется мечтой
Вобщем, по-большому счету должны остаться такие штуки, как сам, собственно, запрос к БД, получение массива из результатов, получение объектов, numrows, и т.д. Короче, курю мануалы, завтра что-то уже будет, я думаю

P.S.: Предыдущий вопрос насчет того, как поступать в классами статей и прочего прошу считать закрытым - вопрос был глупый, никто не мешает мне в классе статей только формировать запрос к БД, а выполнять его классом для работы с БД.

Ну, вот, еще одна попытка.
Пример использования: