ну если для тренировки только, то наверно полезно.
жаль, поторопился, мог бы сэкономить время, если бы лучше продумал архитектуру: сплошной copy-paste
и интерфейс получился не слишком интуитивный, зачем мне вызывать специальную функцию delete или update, если я все-равно должен этот delete  или update продублировать на sql?
тем более что реализовано оно, мягко говоря, не разнообразно

  

baldina, замечая в тему и уже были озвучены. Функции разделены, т.к. в ближайшее время исправлю ситуацию с


То что код получился не слишком интуитивный, согласен. Сейчас конечно мне он понятен, но раньше пришлось по ломать голову. Я ранее писал что за основы и идею взял чужой код, который был работоспособен и отвечал моим "хочу". Но весь код построен на ссылках, я а это очень не люблю..Начал исправлять - полезли ошибки. Т.ч. пока оставил так. 

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

Сейчас задача избавится от лишнего.. т.е. если insert и ему подобные, то в sql-запросе этого не должно быть

Хотя бы по тому, что обработка результатов запроса разная. Для инсерта нужно выдать last_insert_id, а для Delete - количество удаленных строк. Вообще - довольно полезно иметь selectCell, selectRow, insert, delete, update, и т.д. для разных вариантов возвращаемых данных. 

Я как то месяца 4 назад страдал такой же ерундой только в стиле PDO страдал чисто для себя и иза того что нужно было узнать предварительный результат сформулированного запроса в PDO с этим беда.

Мне вот с кешем не понравилось как у вас сделано я сделал у себя просто вызов метода до выполнения prepare и execute  query просто как метод
Цель метода указать использовать каширование


В данном случаи это просто установка флага в классе и инициализация через конфиг адаптера под каширование 


В методах execute query реализована обычная проверка на наличие включения включенного кеша.

В методах feach() реализован схожий функционал PDO получения результата кеша как будто из базы работаем
feachAll работает по прицепу отдать все

В данный момент пишу обучалку ИИ для этого дела что бы медленные запросы система сама кашировала.
Спасибо knsk за идею с шаблонными запросами
Я ток одном месте их использовал при наличии в название таблицы {{table}} подставлять прификс таблицы ( понравилась мне эта фишка в Yii ).

Чуть не забыл почему я выбрал PDO:
Гибче, абстракнее, приятный синтаксис написания,  по скорости: проигрывает капельку mysqli (где то видел тест но сам не проверял).
А именованные плэйсхолдеры повышает наглядность и эффективность использования в отличии от mysqli где просто "?" где иногда просто заставляет считать вопросики...
Хоть сам PDO и поддерживает плэйсхолдеры в стиле "?" (честно не пользовался)....

Планов у меня много и идей хоть отбавляй ( вот времени всегда мало)

неубедительно. вопрос был, не зачем что-то делать, а зачем что-то делать дважды.

В смысле?
писать 

Так?

да

baldina, На мой взгляд - первое из этих слов ->select необходимо, так как оно определяет формат ожидаемого мной оответа. Второе, если эстетические чувства протестуют - можно подставлять внутри функции. Мои эстетические чувства не протестуют. А вот подстановка в некоторых(не всех) функциях - странное и не совсем логичное действие.

Можно делать как DBSimple - выяснять результат, анализируя начало строки запроса. На мой взгляд - это непроизводительная потеря и так нерезинового времени.

можно сделать много чего, в т.ч. красиво и эффективно.
я всего лишь указал на сей недостаток (и Gold Dragon согласился)

Ok! Согласен. Пусть решает дракон   

Согласился, но кажется по горячился...

Тут я поразмышлял малость и прикинул... Допустим я всё упрощаю и удаляю "повторы" в этом
...->insert("INSERT...
Тогда мне нужно передавать не строкой запроса, а переменными

Возьмём запрос для вставки.

Сейчас тут
1 - Запрос
2 - массив с переменными

Если мы хотим избавится от "избыточности", то нам нужно передавать
1 - имя таблицы
2 - массив с именами полей
3 - массив с переменными
и вызов будет примерно такой


Теперь если взять "обновление" и сделать по подобию

То нам нужно передавать 
1 - имя таблицы
2 - массив с именами полей
3 - массив с переменными
4 - массив с именами полей в условии
5 - массив с переменными условия
И получается что-то типа такого


Вот тут то и вопрос: "А не слишком это всё усложняет и загромождает систему?"

Добавлено через 2 минуты и 41 секунду
и это если запросы простые без вложенности

Это сообщение отредактировал(а) Gold Dragon - 19.11.2012, 14:33

По-моему поздно пить боржоми 

адсолютно не поздно.. В крайнем случае можно сделать дополнительные методы

Тут обсуждается построитель запросов? Как показывает практика, строить достаточно адекватно удается только простые запросы. Всякая сложность потребует неадекватного усложнения построителя. Можно посмотреть на сложность activeRecord  в Yii, например.

Тонкость в том,что вся эта сложность нужна ТОЛЬКО для генерации строки SQL. Зачем ее генерировать, если можно просто ее явно  записать? 

Строка SQL может зависеть от конкретного sql-транспорта и незначительно меняться в зависимости от него. Почему бы не пойти по пути "многоязыковых" приложений и не сделать словарь SQL запросов, если действительно нужно работать в нескольких местах? Запросов в приложении не может быть уж очень много, так что словарь вполне реален.

ksnk, не совсем уловил мысль.. На примере покажи