Ti Потому что он будет медленее чем родной интерфейс к базе. К тому же если вы пишите более-менее сложные запросы, они становяться не переносимы между базами данных. Смысл тогда вообще использовать PDO?
Попробовал поработать с debug_backtrace()и понял что вы на все 100% правы! Команда выводит исчерпывающею информацию которой с головой хватит для отладки. Просто с самого начала решил делать по принципу клиент видит только то что ему надо, а в случае ошибки он увидит или красивую страничку с извинением и просьбой зайти по позже или просто банальную строку с сообщением а ля System Fatal Error. При ошибке автоматом в лог записалось бы сообщение об ошибке, откуда она появилась, и во сколько (Обожаю, когда система создает кучу логов о роботе, ошибках, пользователях) но я еще не знал про команду debug_backtrace(), а когда прочитал про нее, то сначала и не понял какой плюс, она может мне дать. Как я посмотрел единственное, что как мне кажется, действительно хорошее, что я придумал это способ задания настроек базы то есть просто: PHP: <?php function Config($array){ if(empty($array)){ $this->error = 'Конфигурация БД не задана'; return false; } $class_vars = get_object_vars($this); foreach ($class_vars as $key => $val){ if (array_key_exists($key, $array)) { $this->$key = $array[$key]; } } return true; }
Буду спорить. 1. PDO такой же "родной" как и расширение mysql - по скорости он точно не медленее. Даже если бы он работал немного медленее, это напоминало бы сравнение циклов for и while. 2. Вас пугает единый интерфейс? Ищете сложности? Жду других аргументов против PDO.
Ti Пугает некоторая громоздкость и сырость. Но это больше придирки. Бесполезность его в том, что серьёзные проэкты совместимыми с другими базами не делают, либо если делают, то это обычно на каждую базу свои SQL запросы. Потому что не используя особенности баз данных вы получите тормоз. Да ещё и не каждый запрос можно написать без них. О всяких поделках типа форумов и CMS'ах, где помимо тупых SELECT, UPDATE, DELETE ничего толком не используеться, мы не говорим.
кода только появился, может быть и был не обкатан, но это было давно и не правда чуть больше года юзаеца на сайте с достаточно большой загрузкой 1500 - 2000 только зареганных юзверей в день, круглосуточно 10мб/с. Все летает, багов PDO не замечал. А при чем тут ваще структура запросов??? Факт, что это уже не первая библиотека на форуме которая делает то же что и PDO, только, ИМХО в разы, НЕ ЛУЧШЕ.
работа с ним не очень удобна, так что полюбому нужно писать обёртку, а раз уж писать обёртку, то без разницы что оборачивать - функции или класс (разве что функции быстрее работают). единственное но: sqlite третьей версии доступен только через PDO либо немедленно нужна поддержка нескольких БД, а писать для неё драйвер к обёртке - лень/нетвремени.
Ti Код (Text): Uptime: 172806 Threads: 1 Questions: 81677650 Slow queries: 0 Opens: 1226 Flush tables: 1 Open tables: 149 Queries per second avg: 472.655 Если сравнить вашу и мою нагрузку - то уж извините, у вас при нормальном современном домашнем ПК разницу между 50 и 100 запросов не почуствуешь. Не говоря уже о том, что у вас кол-во небольшое. У меня много чутче система реагирует, недавно зашкаливало за 600 запросов в секунду, на выходных немного посидел и доработал SQL запросы. З.Ы. У меня NPTL, посему система видит MySQL как один процесс, реально их 8. З.Ы.Ы. Чъя пиписька круче? :lol: Шучу. Вам, кстати, зачем 192(!!!!) потока MySQL'a?!
Ti, заметь, что внутри $row по умолчанию все поля дублируются. я, например, активно использую такие финты: вариант обойтись одним апдейтом - не подходит, ибо получить данные нужно полюбому. на чистом PDO аналогичное будет смотреться громоздко и неуклюже.
разрабчики утверждали что по производилельности это одинаково если вам это не улыбает, вот другой вариант: <? $q = $db->query('SELECT * FROM table'); foreach($q->fetch(PDO::FETCH_ASSOC) as $row) { print_r($row); } ну, гараздо приянее писать только необходимое. PHP: <? class db extends PDO { function insert() { // } }
в данном случае речь не о производительности, а о мусоре вот как раз такой вариант и неулыбает больше всего в том то и дело, что приходится вот так вот оборачивать добрую половину функций
Ti Первое, зачем ВООБЩЕ оборачивать mysql_*, pgsql_* и.т.д. функции во что либо? PHP: <?php /* Standart MySQL, PgSQL ect. */ $result = mysql_query('SELECT * FROM table', $db); if (mysql_num_rows($result)){ while($row = mysql_fetch_assoc($result)){ print_r($row); } }else{ print 'No data'; } /* New MySQLi extension */ $db = new mysqli('host', 'user', 'password', 'dbname'); $result = $db->query('SELECT * FROM table'); if ($result->num_rows){ while ($row = $result->fetch_assoc()){ print_r($row); } }else{ print 'No data'; } /* * PDO * Сразу минус из документации: * # If the last SQL statement executed by the associated PDOStatement was a SELECT statement, some databases # may return the number of rows returned by that statement. However, this behaviour is not guaranteed for # all databases and should not be relied on for portable applications. * * Уже плохо, придёться подругому проверять, а есть ли вообще данные после запроса. Вот вам и кросплатформенность. */ $q = $db->query('SELECT * FROM table'); $i = 0; while($row = $q->fetch(PDO::FETCH_ASSOC)){ print_r($row); $i++; } if ($i == 0){ print 'No data'; } ?> ИМХО, напрямую использовать функции даже проще, код читаеться легко и понятно. Нужен кросплатформенный код? Так вы определитесь что вам вообще надо! Я видел поддержку MySQL, PgSQL и MSSQL вместе, не более! И то, в них есть настолько сильные отличия в SQL синтаксисе, что писать всёравно придёться отдельно. Взять хотя-бы LIMIT в MySQL и PgSQL и TOP в MSSQL. И не говорите что вы не пользуетесь лимитами, они есть практически в любой SELECT'e, результат которого потом выводиться на постраничный вывод. Доводилось поработать и с PostgreSQL, и с MSSQL, на MySQL каждый день работаю, простых вещей не делал, поэтому моё мнение - PDO не поможет. Они слишком разные как по фишкам, так и по синтаксису. А писать сложные запросы не учитывая особенностей работы базы просто глупо, потому что написанный в SQL стандарте запрос может работать на одной базе и не работать на другой. Либо работать везде, но тормозить шописдец. Или на одной прекрасно пашет, на другой вешает сервер на пару секунд пока выполняется. И.т.д. Так что для меня, когда каждый день приходиться составлять запросы вроде этого PHP: <?php $where = ''; $select_field = 'frt_replyes AS page'; if ($this->access < THEME_MODERATOR){ $where = ' AND frt_status != "deleted"'; $select_field = '(SELECT COUNT(*) FROM forums_messages WHERE frm_frt_id = frt_id) AS page'; } $limit = abs((int)ARG1) * $settings['forums_themes_per_page'].','. $settings['forums_themes_per_page']; $result = mysql_query('SELECT frt_id, frt_title, (frt_replyes - 1) AS topic_message_count, frt_views AS topic_views_count, frt_for_id, frt_status, prf.prf_id AS prf_id, prf.prf_nick AS prf_nick, lmp.prf_id AS message_prf_id, IFNULL(lmp.prf_nick, "none") AS message_prf_nick, frm_creation_date AS sort_date, IFNULL(DATE_FORMAT(frm_creation_date, "%d.%m.%Y %H:%i:%s"), 0) AS frm_creation_date, IFNULL(frm_id, 0) AS frm_id, frt_last_frm_id, '.$select_field.', IF(TIMESTAMPDIFF(day, frt_update_date, NOW()) > '.$settings['forums_topic_highlight'].', -1, 0) AS unread, frt_closed, IF(IFNULL(frt_sticky_till, 0) != 0, IF(frt_sticky_till < NOW(), 3, 2), (frt_sticky + 0)) AS sort_sticky, IF(IFNULL(frt_sticky_till, 0) != 0, IF(frt_sticky_till < NOW(), "no", "yes"), frt_sticky) AS frt_sticky, IF(IFNULL(frt_marked, 0) > NOW(), "yes", "no") AS frt_marked, fme_prf_id, fme_prf_nick, DATE_FORMAT(fme_creation_date, "%d-%m-%Y %H:%i:%s") AS fme_creation_date, IF(fme_creation_date < NOW() - INTERVAL 1 WEEK, NULL, fme_comment) AS fme_comment FROM forums_topics LEFT JOIN forums_events ON frt_fme_id = fme_id LEFT JOIN forums_messages ON frm_id = frt_last_frm_id LEFT JOIN profiles AS prf ON prf.prf_id = frt_prf_id LEFT JOIN profiles AS lmp ON lmp.prf_id = frm_prf_id WHERE frt_for_id = '.(int)$this->forum_id.$where.' ORDER BY sort_sticky ASC, sort_date DESC LIMIT '.$limit, $database); $total_records = mysql_result(mysql_query('SELECT COUNT(*) FROM forums_topics WHERE frt_for_id = '.(int)$this->forum_id.$where, $database), 0, 0); ?> PDO идёт лесом сразу.
сочувствую, ник подходящий а почему не на ассамблере? рекомендую 10 раз подумать о односложных предложениях и понятной логике, прежде чем такое лепить. на крайняк оборачивать в методы, ибо это СТРАШНО.
Ti А SQL процедуры в MSSQL на 2500 строк для выставления счетов за месяц в биллинге большой компании тоже страшно? Это, между прочим, самый правильный подход. Со стороны в базу данных пользователи вообще не имеют доступа к таблицам, только к процедурам. Ими они и оперируют, операции SELECT, UPDATE и.т.д. просто запрещены, только вызов процедур. В серьёзных проэктах это нормально. При больших объёмах баз данных (а она у нас уже сейчас 5+ GB, и каждый день растёт на пару сотен мегабайт, есть таблицы где уже по 1.5-2 миллиона записей, а это только начало, будет больше. Уже сейчас SQL сервер обслуживает больше 1500 запросов в секунду, представте сколько их будет если написать 5 запросов а не один, сервер загнёться) выполнить даже 2 запроса вместо одного уже можеть быть медленее чем 1 более сложный, но хорошо оптимизированный запрос. Я уже не говорю про 3-4 и более.
Да, PHP. Но PHP программист должен хорошо знать SQL и уметь его применять на полную катушку, а не половина на SQL, половина на PHP. Если вы умеете составлять не сильно сожные запросы да и только - далеко вы не уйдёте. Так что идиальные знания SQL'a необходимы для работы в больших и прибыльных проэктах и компаниях.
Никто о фанатстве и не говорит. Просто в больших системах надо больше пользоваться SQL'om, будет проще и менее тормознуто