• PHP json_decode проблема с кириллицей?

    misterfil
    @misterfil
    PHP программист(Full Stack)
    <?php
    $data_json = utf8_encode($data_json); 
    $results = json_decode($data_json);
    Ответ написан
    1 комментарий
  • Сложный select в mysql с тремя таблицами?

    Sanasol
    @Sanasol Куратор тега Laravel
    нельзя просто так взять и загуглить ошибку
    select text, (select count(*) from feedbacks_likes where feedback_id = feedbacks.id) as likes, (select count(*) from feedbacks_dislikes where feedback_id = feedbacks.id) as dislikes from feedbacks

    Легкий селект, только структура базы глупая.
    В идеале хранить готовое число лайков и дислайков, чтобы не считать каждый раз.
    Ответ написан
    3 комментария
  • Как правильно реализовать ООП класс базы данных с PDO?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Я уже отвечал как-то на подобный вопрос. И не один раз. И не два.
    Поскольку мозги всех пользователей пхп ходят по одним и тем же рельсам, не сворачивая. Впрочем, не всех. 85% всю жизнь продолжают писать mysl_query, которую выучили из видеоурока, и не видят в этом проблем. И только у самых талантливых 15-и процентов в какой-то момент возникает мысль ВСЁ АВТОМАТИЗИРОВАТЬ. Это, на самом деле, хороший знак. Такое желание как раз и отличает потенциального программиста от клепальщика гуано-кода.

    Но всё портит недостаток знаний в SQL. Искренне полагая SQL не более чем key-value хранилищем, они всерьез уверены в том, что функция select() с двумя аргументами - это все что им надо.

    Настоятельно рекомендую прочесть аргументацию по ссылке выше.

    После этого понять, что существует ТРИ класса классов для работы с БД:

    1. DB-хелпер. Класс, берущий на себя всю грязную работу по исполнению запросов. В случае с ПДО не сильно-то и нужен. Позволяет исполнять любые запросы. НИКАКИХ функций типа select(), ограничивающих функциональность, в нем быть не должно ни в коем случае.
    2. Query builder. Функция типа select() может быть только в квери билдере, который маскирует SQL в функции РНР. Заведомо ущербен по сравнению с первым, но зато позволяет использовать запросы более сложные, чем ORM.
    3. ORM. То, что начинающему пользователю на самом деле нужно, но он об этом просто не догадывается. Как раз та самая волшебная палочка, которая делает примитивное доставание данных из базы по первичному ключу столь маняще единообразным.

    Cамое главное, что надо понять:
    Все вышеперечисленное - это РАЗНЫЕ типы классов, не имеющие между собой ничего общего.
    И не пытаться под видом первого городить нежизнеспособное второе, имея в виду третье. Надо очень четко понимать, что сначала делаем первое, а потом, на его основе - либо второе, либо третье. Но не все вместе.

    А можно не пытаться изобретать велосипед, а использовать готовое. Например - популярный фреймворк. Тогда желаемая функция будет выглядеть вот так:

    public function viewUser($id)
    {
        return User::model()->findByPk($id);
    }

    Это в самом предпочтительном случае - при использовании ORM.
    На квери билдере это будет что-то вроде
    public function viewUser($id)
    {
        return DB::select('*')->from('users')->where("id", '=', $id);
    }


    При этом можно использовать и чистый SQL. Запрос прямо в классе юзера - это не так уж и страшно. Тем более, что есть такие запросы, которые по другому просто не выполнишь. Другое дело, что всю работу по исполнению запроса должен брать на себя хелпер. Пример можно посмотреть по ссылке выше - там хоть и SQL , но того ужаса, который здесь, нету:
    public function viewUser($id)
    {
        $sql = 'SELECT * FROM users WHERE id=?';
        return DB::prepare($sql)->execute([$id])->fetch();
    }
    Дальнейшую работы над классом можно производить только после того как ты определишься, какой именно класс ты хочешь написать.
    Ответ написан
  • Как добавить в дочерний класс функцию с PDO?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Просто классическая коллекция заблуждений, связанных с бд-врапперами.

    1. Не надо писать функцию select().

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

    В итоге из практически натурального английского "выбрать все поля из таблицы пользователей, где логин равен тому-то и пароль тому-то" получаем на выходе непонятные иероглифы, про значение которых автор и сам забудет через пару месяцев.
    $this->db->select('*', 'ftl_workers', "login = ? AND password = ?");

    в этом коде автор экономит себе три слова.
    Вопрос: стоит ли эта экономия читабельности и портируемости?
    Вопрос: а что будет, когда автор узнает о других операторах SQL, таких, как GROUP BY, JOIN и пр.?
    Неужели так сложно написать нормальный SQL запрос:
    $this->db->get('SELECT * FROM ftl_workers WHERE login = ? AND password = ?");

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

    2. Самые развесистые грабли. Класс бизнес-логики наследует классу БД. ООП же! Надо же что-то наследовать! При этом совсем не приходит автору в голову, что, скажем, пользователь - это не база данных! И нет ни одной причины наследовать первого от второй. БД может присутствовать в классе как сервис. Как свойство. Но не как. праордитель

    3. по какой-то неизвестной причине все поголовно писатели врапперов делают параметры доступа к базе переменными класса. Ну, видимо, чисто для солидности. при этом им не приходит в голову, что переменные
    а) должны приходить из конфига
    б) используются ровно один раз, в одной-единственной функции и больше никак в жизни класса не участвуют.
    Вопрос: какой смысл делать эти параметры переменными класса?

    4. Как всегда, исключение кидается только для того, чтобы ТУТ ЖЕ его поймать и радостно вывалить на экран. И здесь мы опять видим совершенно поголовное убеждение пользователей похапе в том, что они являются единственными и эксклюзивными пользователями своего сайта. Средний похапешник совершенно искренне не понимает, что у сайта могут быть и другие пользователи, которые эти сообщения ни к чему. А сам он не всегда сидит за монитором, чтобы увидеть сообщение об ошибке.
    И это при том, что сам РНР обработает исключение в сто раз лучше - главное просто ему не мешать. Подробнее можно прочитать здесь: phpfaq.ru/pdo#exceptions

    В итоге, без переменных класса, функции Селект и "обработчика" ошибок от класса не остаётся ничего. И это правильно. PDO - это уже дб-враппер, и "расширять" его - только портить. Во всяком случае, начинающим похапешникам настоятельно рекомендуется этого не делать, а научиться сначала пользоваться родным PDO.

    Если уж так уж прям хочется сэкономить одну строчку, то изменения нужны совсем крошечные:
    - надо сделать так, чтобы prepare возвращала statement, и singleton по вкусу.
    получается https://github.com/colshrapnel/thebestpdowrapper
    С нормальным враппером код остаётся читаемым, но в то же время кратким:

    class UserAuth {
        function check($user, $pass) {
            $sql = 'SELECT * FROM ftl_workers WHERE login = ? AND password = ?';
            return DB::prepare($sql)->execute([$user, $pass])->fetch();
        }
    }
    include 'bestpdo.php';
    $ua = new UserAuth();
    $ua->check('admin', 'pqwe');
    Ответ написан
    5 комментариев