ФорумПрограммированиеPHP для идиотов → Класс для работы с БД

Класс для работы с БД

  • Baboot

    Сообщения: 440 Репутация: N Группа: Адекваты

    Spritz 19 августа 2009 г. 14:57, спустя 20 минут 39 секунд


    AndryG, молодец!

    по теме
    1. редко надо вызывать более 1го запроса с разными данными.
    2. в пхп все не по человечески, но мы его любим
    3. инъекции не проходят и про mysql_real_escape_string так что если учесть (1.) я думаю что скорость будет одинаковая, может я неправ. переубедите
    4. больше коду - больше шанс на ошибку
    5. умные книги продают чтобы их покупали, а никак не чтобы по ним учились :)

    Спустя 5 сек.
    я не быдло.


    +1
  • AndryG

    Сообщения: 237 Репутация: N Группа: Адекваты

    Spritz 19 августа 2009 г. 15:15, спустя 18 минут 28 секунд

    Если бы в Ваш рапозиторий не видел, то точно решил бы, что быдло.

    А по пунктам - можно спорить до посинения … но зачем?
    Одни исповедуют mysql_real_escape_string, другие  prepared statement.

    Я в ветку ввязался с идеей "стандартизации костылей" и широкому использованию благ цивилизации.
    И свою мысль я уже довел.
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 19 августа 2009 г. 15:18, спустя 2 минуты 20 секунд

    да костыли в любом случае будут :)

    Сапожник без сапог
  • Givi

    Сообщения: 2284 Репутация: N Группа: Адекваты

    Spritz 19 августа 2009 г. 16:15, спустя 56 минут 52 секунды

    Да и костыли в данном случае служат разные цели для каждого :) Кому-то создать "безопасность", а кому-то для сбора статистики по запросам и их видам.
  • Batler

    Сообщения: 142 Репутация: N Группа: Кто попало

    Spritz 19 августа 2009 г. 19:28, спустя 3 часа 13 минут 40 секунд


    Параметры и prepared statement:
     - составили код запроса. На место данных ставим :param_name (В php тоже не по человечески .. требует на место параметра ставить ?)
     - подготавливаем запрос (СУБД анализирует код запроса, составляет его план и т.д.) -  получаем подготовленный запрос
     - подг. запросу указываем наши данные как значения параметров и выполняем его

    Если выполняется много-много раз один и тот же запрос с разными данными(значениями параметров), то вариант с предварительной его подготовкой дает значительный прирост производительности, ибо СУБД не тратит время на парсинг запроса и его анализ, а сразу использует для выполнения подготовленный запрос.

    О безопасности. Какие бы вы данные не указали в значении параметра - они никак не могут повлиять на выполнение запроса, ибо сам запрос уже проанализирован СУБД и для него уже создан "сценарий выполнения". Все ваши инъекции отныне будут рассматриваться не как код запроса, а как значение параметра, над которым будет издеваться СУБД по уже известному ей сценарию.

    Во, блин, написал … точнее смотрите умные книги :-)


    Опять же, применимо ли это к MySQL? Смотрим вот эту ссылку:
    http://dev.mysql.com/doc/refman/5.0/en/sql-syntax-prepared-statements.html
    Совершенно другой синтаксис. К тому же есть ряд ограничений.
    Здесь вообще говорится о падении производительности:
    http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

    И синтаксис ? - это не приблуда php, а приблуда MySQL.

    И вообще операторы подготовленных запросов есть в стандарте?
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 19 августа 2009 г. 19:33, спустя 4 минуты 42 секунды

    в мускуле и правда падает производительность от препаредов, я тоже где то читал
    Сапожник без сапог
  • AndryG

    Сообщения: 237 Репутация: N Группа: Адекваты

    Spritz 19 августа 2009 г. 21:55, спустя 2 часа 22 минуты 4 секунды

    Запрессовали :)

    Кто читал, а не смотрел, тот понял, что я хотел сказать.

    Давайте лучше к классу вернемся.
  • Batler

    Сообщения: 142 Репутация: N Группа: Кто попало

    Spritz 19 августа 2009 г. 22:01, спустя 5 минут 36 секунд

    Да нет, лично я понял что вы хотели сказать :)
    Видите, просто то что вы говорите - не совсем применимо к БД MySQL (см выше ссылки почему).

    По поводу класса мне было бы интересно узнать какой формат данных стоит поддерживать в результате.

    Пока с результатом можно сделать следующее: afr - affected rows, assoc - ассоциативный массив.
    Ну и вроде массив список тоже…

    Да кстати, если будет реальный интерес к использованию - подготовлю доку и выложу код (ну и устраню/дополню косяки)…
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 19 августа 2009 г. 22:03, спустя 2 минуты 37 секунд


    Да нет, лично я понял что вы хотели сказать :)
    Видите, просто то что вы говорите - не совсем применимо к БД MySQL (см выше ссылки почему).

    По поводу класса мне было бы интересно узнать какой формат данных стоит поддерживать в результате.

    Пока с результатом можно сделать следующее: afr - affected rows, assoc - ассоциативный массив.
    Ну и вроде массив список тоже…

    Да кстати, если будет реальный интерес к использованию - подготовлю доку и выложу код (ну и устраню/дополню косяки)
    я всегда так же говорю ….
    Спустя 14 сек.
    или я хуйло, или все такие …
    Сапожник без сапог
  • md5

    Сообщения: 11960 Репутация: N Группа: в ухо

    Spritz 19 августа 2009 г. 22:09, спустя 5 минут 15 секунд

    все хуйлы..
    все умрут, а я изумруд
  • AndryG

    Сообщения: 237 Репутация: N Группа: Адекваты

    Spritz 20 августа 2009 г. 17:29, спустя 19 часов 20 минут 9 секунд


    По поводу класса мне было бы интересно узнать какой формат данных стоит поддерживать в результате.

    Если я правильно Вас понял, то ещё довольно удобна, как по мне, такая штука…
    Стандартный вариант получения данных fetch_all_assoc() - вернет массив ассоциированных массивов данных.

    Получаем данные в "assoc" массиве:

    array(
    1 => array(id = 34, value = 123, value2 = 321),
    2 => array(id = 56, value = 4234, value2 = 4324))


    Удобно. Но ещё можно и так:

    array(
    34 => 123),
    56 => 4234)

    Спустя 57 сек.
    И так:

    array(
    34 => array(value = 123, value2 = 321),
    56 => array(value = 4234, value2 = 4324))

  • AndryG

    Сообщения: 237 Репутация: N Группа: Адекваты

    Spritz 20 августа 2009 г. 17:42, спустя 13 минут 47 секунд

    У меня это делает функция:

     function array_id2key($array,$name_id='id',$name_value=null){
       $res = array();
       foreach ($array as $k=>$v) $res[$v[$name_id]] = is_null($name_value) ? $v : $v[$name_value];
       return $res;
     }
    Используется примерно так: (всё никак руки не дойдут интегрировать эту функцию в метод fetch_xxx класса БД)
      /**
     * Возвращает список открытых аукционов.
     * AUCTION_ID => NAME
     * @return array
     */
     public function listbr(){
       $res = array_id2key($this->db->newQuery(__METHOD__)->
         execute('select id, name from vvka_auctionbr where state = 1')->fetch_all(),'id','name');
       return $res;
     }

Пожалуйста, авторизуйтесь, чтобы написать комментарий!