всмысле какой? PDO это уже класс. наследуйся от него и пиши более высокоуровневые функции, какие тебе нужны уже. можно active Record рекорд забабахать, можно ORM... а можно и готовый взять, в какомнить фреймворке.
по поводу этого MIner, как я понял это просто конструктор запросов. конечно на любителя, но я вот честно невижу разницы: Код (Text): SELECT * FROM shows INNER JOIN episodes ON shows.show_id = episodes.show_id WHERE shows.network_id = 12 ORDER BY episodes.aired_on DESC LIMIT 20 Код (PHP): $Miner->select('*') ->from('shows') ->innerJoin('episodes', 'show_id') ->where('shows.network_id', 12) ->orderBy('episodes.aired_on', Miner::ORDER_BY_DESC) ->limit(20); подобные классы должны облегчать составление, а не просто её полностью дублировать. экранирование,плейсхолдеры,безопасность...? так это есть и в базовом PDO и сделано удобно. возможность миграции на разные БД? если я наверчу сначала запросов для мускула с его LIMIT + специфичные функции... то при миграции на Оракл,например, у меня один хер все навернется, и придется править запросы и менять логику составления. тоесть профит=0. ТС. чтобы найти(или написать) удобный класс - для начала определись, что именно тебе от него нужно? чего сейчас не хватает? почему вообще задался таким поиском? и далее, искать именно то что покрывает твои нужны.
здесь фишка не в копировании составления запроса, а в том, что можно создать один конструктор и в классе его конструировать-конструировать, передать другому классу что он добавил что-то, потом вернул и уже запустить запрос. Да, это требуется не часто, но требуется. И в таком случае конструктор очень облегчает работу, в других случаях конечно он не очень то и нужен. Если вы собираетесь использовать "особые" методы движка, то никакой универсальный класс не предоставит вам возможность переноса. Насчет LIMIT MySQL'a его можно писать также через LIMIT # OFFSET #. Плюс не забывайте про версии языка SQL, которые поддерживаются движками. + Как раз конструктор может легко решить проблему с LIMIT'ом MySQL'а. и для TC, посмотрите в сторону ORM, может они окажутся для вас полезными или наведут на мысли какие-нибудь. (в Doctrine например есть уже конструктор запросов)
Это понятно. но согласитесь, странно использовать движек, не используя его сильные стороны и особенности. помимо LIMIT есть много специфичных функций, которые могут отличаться названием, параметрами, или вообще отсутствовать ... и при миграции все ранво будет много ручной работы по отлову и исправлению багов. подобные универсальные классы в этой ситуации никак не спасают. в остальном согласен. если нужны дикие динамические конструкторы запросов, то возможно miner хорошее решение.
Что нужно? Уйти от mysql_* функций Куда? Варианта собственно два: mysqli_* или PDO Все, включая разработчиков пхп за PDO, отсюда и вопрос собственно Подводя итоги, если не требуется чего то супер пупер, то проще самому написать несколько функций: получить одну строку несколько делит инсерт апдейт
посмотрите в сторону ОРМ и подобные вопросы вас посещать не будут. нафига велосипеды придумывать, когда куча бесплатных и довольно быстрых и удобных? я знаю нафига. тупо лень разбираться и подстраиваться под чужое мышление. ве равно лет через 5 прийдете к орм, если программить будете.
Согласен, НО если задача стоит "Программа должна работать на этом, этом, этом и этом движке", то использование каких-то особых фишек отменяется автоматически. Если же программа пишется под что-то одно (как частенько бывает, особенно в корпоративной среде), то об этом можно не задумываться и уж точно не брать такой конструктор "на будущее для переноса"
Толстовато Сейчас только-что в Kohan'e сидел оптимизировал кол-во запросов к БД у ORM на одной толстой странице админки, матерился. Сейчас где-нибудь отдельно отпишсьу, дабы если кому будет нужно искалось нормально бы.
Когда все выдержано в OOП, ковыряние в массивах расстраивает ) Да и во вьюхах, както структуры типа: $item->child->name удобнее, чем массив, учитывая то, что если child-а еще нет, то ORM подтащит его.