Comments 21
1. По данному вопросу я очень долго сомневался, стоит ли вообще постить? Ведь действительно, функции нынче не модны, но я преследовал в первую очередь задачу иную: получить для себя простой, удобный инструмент без лишних наворотов. На мой взгляд, цель достигнута. Из примера каждый сможет для себя подсмотреть ошибки, недостатки и положительные моменты, а затем «обернуть» так, как уже душе будет угодно.
2. Идея суперская и, стоит признать, вертится у меня в голове уже давно, но не доходят руки, т.к. повторюсь — PHP — это лишь малая часть моего времени и все проекты, которые мне приходится реализовывать, достаточно просты по своему функционалу. Если действительно написать то, что Вы предложили, можно всецело двинуться в сторону решения проблемы построения сложных запросов а-ля «хочу, чтобы было хорошо», но, но, но… каждая задача требует своих ресурсов, я прав?
3. Как говорится, по просьбе трудящихся (комментарии убрал, в зип обернул)
2. Идея суперская и, стоит признать, вертится у меня в голове уже давно, но не доходят руки, т.к. повторюсь — PHP — это лишь малая часть моего времени и все проекты, которые мне приходится реализовывать, достаточно просты по своему функционалу. Если действительно написать то, что Вы предложили, можно всецело двинуться в сторону решения проблемы построения сложных запросов а-ля «хочу, чтобы было хорошо», но, но, но… каждая задача требует своих ресурсов, я прав?
3. Как говорится, по просьбе трудящихся (комментарии убрал, в зип обернул)
Задача, конечно же, была вторая — создать легкий и удобный инструмент. Однако я не рискну это оборачивать во что бы то ни было, т.к. не думаю, что у меня получится сделать что-то действительно супер-универсальное и супер-совместимое с другими проектами. Я никогда не делал на PHP действительно серьезных проектов и всей специфики построения «красивых» классов я просто не знаю по роду своей деятельности. В итоге может получиться что-то еще более страшное и неудобное, чем эти ф-ции. Поэтому данный пример — ни что иное, как пример и легкий инструмент, когда Вам не нужен мобильный телефон с камерой\игровой приставкой\стиральной машинкой, а нужен просто телефон, чтобы звонить. Если Вы хотите сменить в нем корпус, сделав его помимо звонилки еще и красивым, то никто Вам этого не мешает сделать самому. В конце-то концов, у всех свои вкусы и подходы.
Обернул в ООП. В посте все ссылки на старую и на новую версию.
Если конструктор может работать только с простыми запросами, то для формирования сложных придется использовать другое средство. А использование в коде двух разных средств для одной и той же работы — это еще хуже чем фреймворки. Ваш прием хорошо подойдет для обработки пользовательских форм, но для этого его надо засунуть в класс, как справедливо заметил nord_ua. Так будет практичнее.
А чем вам функция filter_input_array не подошла?
Может лучше это: dklab.ru/lib/DbSimple/?
А это уже полноценный класс для работы с БД. Я очень не люблю накручивать все, как сказал однажды один товарищ, что нет особо смысла обертывать в бесконечные ООП MySQL-запросы, нет ничего более читабельного, чем чистейший SQL-запрос. Опять же встает вопрос удобства применения и удобства использования данного класса внутри своего конкретного проекта.
> нет ничего более читабельного, чем чистейший SQL-запрос
Подозреваю ваши запросы по сложности не пошли дальше описанных в первых главах учебников по SQL.
код при работе с ORM, как по мне, читается намного проще.
Подозреваю ваши запросы по сложности не пошли дальше описанных в первых главах учебников по SQL.
код при работе с ORM, как по мне, читается намного проще.
Подозревать Вы можете что угодно, где угодно и когда угодно, но если я буду продолжать дискуссию — это выльется в холивар, Вам это надо? Да и мне не за чем и не перед кем оправдываться и показывать в свет что-то более сложное.
В конце концов, каждый пользуется тем, что считает для себя оптимальным. В рамках данного скрипта не нужно даже и SQL знать: сформировал массив с полями из таблицы и получил готовый ответ. Чем не красота?
В конце концов, каждый пользуется тем, что считает для себя оптимальным. В рамках данного скрипта не нужно даже и SQL знать: сформировал массив с полями из таблицы и получил готовый ответ. Чем не красота?
Не совсем по теме, но всё же. Функция custom_addslashes со вторым параметром true вряд ли справится с фильтрацией, как это задумано. Если задано значение параметра $Value равным, например, ..>/..>/..>/etc/passwd, то функция отработает, и на выходе будет ../../../etc/passwd. Так что эту функцию стоит пересмотреть точно.
А мне нравится как это сделано в Doctrine, а так же щас работаю в Yii, там тоже весьма вставляет.
По-моему, вы пытаетесь сделать некое подобие ORM-прослойки. Таких уже сделано немало: Doctrine, Propel. Это ещё не фреймворки, но в работе с базой здорово помогут.
Когда займётесь кросстабличными запросами, ваш конструктор запросов рискует вырасти в некое подобие вышеупомянутых ORM-механизмов, и вам придётся делать выбор: тянуть своё или перейти на готовое и годами отлаженное.
Когда займётесь кросстабличными запросами, ваш конструктор запросов рискует вырасти в некое подобие вышеупомянутых ORM-механизмов, и вам придётся делать выбор: тянуть своё или перейти на готовое и годами отлаженное.
Вы правы в том отношении, что "… когда займетесь трам-парам...", то да, действительно, проще взять готовые вещи.
Я решал локальную задачу — удобство фильтрации по одной базе с минимумом ресурсных и силовых затрат. Очень не хотелось подтягивать тонны ненужного мне кода, который я 100% знаю, что никогда не буду использовать в рамках данного проекта. Потому, собственно, и родилась подобная реализация.
Я решал локальную задачу — удобство фильтрации по одной базе с минимумом ресурсных и силовых затрат. Очень не хотелось подтягивать тонны ненужного мне кода, который я 100% знаю, что никогда не буду использовать в рамках данного проекта. Потому, собственно, и родилась подобная реализация.
id > = 88 АND id < = 10 // кавычки убраны из за парсера
может быть все таки стоит сравнивать данные полей перед передачей в запрос?
может быть все таки стоит сравнивать данные полей перед передачей в запрос?
Можно, только всех вариантов не предусмотришь. Можно набрать 10 критериев по ID и все они будут противоречить друг другу. Поэтому данный случай я уже оставил на совесть СУБД, т.к. результат запроса будет пустой. Но только надо ли кому-то тут себе вредить, просто так подгружая впустую СУБД? Ну разве что только тестов ради
Хотя Вы все же правы. Вот данный конкретный момент я поправил. Действительно ни к чему такой критерий вставлять в запрос.
Sign up to leave a comment.
Фильтруй базар: пишем простой и функциональный фильтр данных