За последние 24 часа нас посетили 19414 программистов и 1021 робот. Сейчас ищут 613 программистов ...

Написал класс роботы с MySQL проверте

Тема в разделе "Решения, алгоритмы", создана пользователем oligarx, 13 апр 2007.

Статус темы:
Закрыта.
  1. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    2ALL почему не PDO?
     
  2. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    чем он тебе ненравится?

    при каждом запросе к бд? да.
     
  3. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    Потому что он будет медленее чем родной интерфейс к базе.
    К тому же если вы пишите более-менее сложные запросы, они становяться не переносимы между базами данных. Смысл тогда вообще использовать PDO?
     
  4. oligarx

    oligarx Активный пользователь

    С нами с:
    23 янв 2007
    Сообщения:
    68
    Симпатии:
    0
    Адрес:
    Украина Львов
    Попробовал поработать с debug_backtrace()и понял что вы на все 100% правы! Команда выводит исчерпывающею информацию которой с головой хватит для отладки.

    Просто с самого начала решил делать по принципу клиент видит только то что ему надо, а в случае ошибки он увидит или красивую страничку с извинением и просьбой зайти по позже или просто банальную строку с сообщением а ля System Fatal Error. При ошибке автоматом в лог записалось бы сообщение об ошибке, откуда она появилась, и во сколько (Обожаю, когда система создает кучу логов о роботе, ошибках, пользователях) но я еще не знал про команду debug_backtrace(), а когда прочитал про нее, то сначала и не понял какой плюс, она может мне дать.

    Как я посмотрел единственное, что как мне кажется, действительно хорошее, что я придумал это способ задания настроек базы то есть просто:
    PHP:
    1. <?php
    2. function Config($array){
    3.   if(empty($array)){
    4.     $this->error = 'Конфигурация БД не задана';
    5.     return false;
    6.   }
    7.   $class_vars = get_object_vars($this);
    8.   foreach ($class_vars as $key => $val){
    9.     if (array_key_exists($key, $array)) {
    10.       $this->$key = $array[$key];
    11.     }
    12.   }
    13.   return true;
    14. }
     
  5. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    Буду спорить.

    1. PDO такой же "родной" как и расширение mysql - по скорости он точно не медленее.
    Даже если бы он работал немного медленее, это напоминало бы сравнение циклов for и while.

    2. Вас пугает единый интерфейс? Ищете сложности?

    Жду других аргументов против PDO.
     
  6. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    Пугает некоторая громоздкость и сырость. Но это больше придирки.

    Бесполезность его в том, что серьёзные проэкты совместимыми с другими базами не делают, либо если делают, то это обычно на каждую базу свои SQL запросы. Потому что не используя особенности баз данных вы получите тормоз. Да ещё и не каждый запрос можно написать без них. О всяких поделках типа форумов и CMS'ах, где помимо тупых SELECT, UPDATE, DELETE ничего толком не используеться, мы не говорим.
     
  7. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    кода только появился, может быть и был не обкатан, но это было давно и не правда
    чуть больше года юзаеца на сайте с достаточно большой загрузкой 1500 - 2000 только зареганных юзверей в день, круглосуточно 10мб/с. Все летает, багов PDO не замечал.
    А при чем тут ваще структура запросов???
    Факт, что это уже не первая библиотека на форуме которая делает то же что и PDO, только, ИМХО в разы, НЕ ЛУЧШЕ.
     
  8. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    работа с ним не очень удобна, так что полюбому нужно писать обёртку, а раз уж писать обёртку, то без разницы что оборачивать - функции или класс (разве что функции быстрее работают). единственное но: sqlite третьей версии доступен только через PDO либо немедленно нужна поддержка нескольких БД, а писать для неё драйвер к обёртке - лень/нетвремени.
     
  9. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    НЕУДОБНО???

    PHP:
    1. <?
    2. $q = $db->query('SELECT * FROM table');
    3. foreach($q as $row) {
    4.    print_r($row);
    5. }
     
  10. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    Код (Text):
    1. 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?!
     
  11. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    192 обращения на момент снятия статы
     
  12. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    Ti, заметь, что внутри $row по умолчанию все поля дублируются. я, например, активно использую такие финты:
    вариант обойтись одним апдейтом - не подходит, ибо получить данные нужно полюбому.
    на чистом PDO аналогичное будет смотреться громоздко и неуклюже.
     
  13. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    разрабчики утверждали что по производилельности это одинаково

    если вам это не улыбает, вот другой вариант:
    <?
    $q = $db->query('SELECT * FROM table');
    foreach($q->fetch(PDO::FETCH_ASSOC) as $row) {
    print_r($row);
    }

    ну, гараздо приянее писать только необходимое.
    PHP:
    1. <?
    2. class db extends PDO {
    3.     function insert() {
    4.         //
    5.     }
    6. }
     
  14. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    в данном случае речь не о производительности, а о мусоре :)

    вот как раз такой вариант и неулыбает больше всего :)

    в том то и дело, что приходится вот так вот оборачивать добрую половину функций :)
     
  15. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    dark-demon
    ИМХО, Ваши аргументы не убедительны.


    Вопрос открыт
     
  16. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    Первое, зачем ВООБЩЕ оборачивать mysql_*, pgsql_* и.т.д. функции во что либо?
    PHP:
    1. <?php
    2. /* Standart MySQL, PgSQL ect. */
    3. $result = mysql_query('SELECT * FROM table', $db);
    4. if (mysql_num_rows($result)){
    5.     while($row = mysql_fetch_assoc($result)){
    6.         print_r($row);
    7.     }
    8. }else{
    9.     print 'No data';
    10. }
    11.  
    12. /* New MySQLi extension */
    13. $db = new mysqli('host', 'user', 'password', 'dbname');
    14. $result = $db->query('SELECT * FROM table');
    15. if ($result->num_rows){
    16.     while ($row = $result->fetch_assoc()){
    17.         print_r($row);
    18.     }
    19. }else{
    20.     print 'No data';
    21. }
    22.  
    23. /*
    24. * PDO
    25. * Сразу минус из документации:
    26. *
    27. # If the last SQL statement executed by the associated PDOStatement was a SELECT statement, some databases
    28. # may return the number of rows returned by that statement. However, this behaviour is not guaranteed for
    29. # all databases and should not be relied on for portable applications.
    30. *
    31. * Уже плохо, придёться подругому проверять, а есть ли вообще данные после запроса. Вот вам и кросплатформенность.
    32. */
    33. $q = $db->query('SELECT * FROM table');
    34. $i = 0;
    35. while($row = $q->fetch(PDO::FETCH_ASSOC)){
    36.     print_r($row);
    37.     $i++;
    38. }
    39. if ($i == 0){
    40.     print 'No data';
    41. }
    42. ?>
    ИМХО, напрямую использовать функции даже проще, код читаеться легко и понятно. Нужен кросплатформенный код? Так вы определитесь что вам вообще надо! Я видел поддержку MySQL, PgSQL и MSSQL вместе, не более! И то, в них есть настолько сильные отличия в SQL синтаксисе, что писать всёравно придёться отдельно. Взять хотя-бы LIMIT в MySQL и PgSQL и TOP в MSSQL. И не говорите что вы не пользуетесь лимитами, они есть практически в любой SELECT'e, результат которого потом выводиться на постраничный вывод.

    Доводилось поработать и с PostgreSQL, и с MSSQL, на MySQL каждый день работаю, простых вещей не делал, поэтому моё мнение - PDO не поможет. Они слишком разные как по фишкам, так и по синтаксису. А писать сложные запросы не учитывая особенностей работы базы просто глупо, потому что написанный в SQL стандарте запрос может работать на одной базе и не работать на другой. Либо работать везде, но тормозить шописдец. Или на одной прекрасно пашет, на другой вешает сервер на пару секунд пока выполняется. И.т.д.

    Так что для меня, когда каждый день приходиться составлять запросы вроде этого
    PHP:
    1. <?php
    2. $where = '';
    3. $select_field = 'frt_replyes AS page';
    4. if ($this->access < THEME_MODERATOR){
    5.     $where = ' AND frt_status != "deleted"';
    6.     $select_field =  '(SELECT COUNT(*) FROM forums_messages WHERE frm_frt_id = frt_id) AS page';
    7. }
    8. $limit = abs((int)ARG1) * $settings['forums_themes_per_page'].','. $settings['forums_themes_per_page'];
    9. $result = mysql_query('SELECT
    10.     frt_id, frt_title, (frt_replyes - 1) AS topic_message_count, frt_views AS topic_views_count,
    11.     frt_for_id, frt_status, prf.prf_id AS prf_id, prf.prf_nick AS prf_nick,
    12.     lmp.prf_id AS message_prf_id, IFNULL(lmp.prf_nick, "none") AS message_prf_nick,
    13.     frm_creation_date AS sort_date,
    14.     IFNULL(DATE_FORMAT(frm_creation_date, "%d.%m.%Y %H:%i:%s"), 0) AS frm_creation_date,
    15.     IFNULL(frm_id, 0) AS frm_id, frt_last_frm_id, '.$select_field.',
    16.     IF(TIMESTAMPDIFF(day, frt_update_date, NOW()) > '.$settings['forums_topic_highlight'].', -1, 0) AS unread,
    17.     frt_closed,
    18.     IF(IFNULL(frt_sticky_till, 0) != 0, IF(frt_sticky_till < NOW(), 3, 2), (frt_sticky + 0)) AS sort_sticky,
    19.     IF(IFNULL(frt_sticky_till, 0) != 0, IF(frt_sticky_till < NOW(), "no", "yes"), frt_sticky) AS frt_sticky,
    20.     IF(IFNULL(frt_marked, 0) > NOW(), "yes", "no") AS frt_marked,
    21.     fme_prf_id, fme_prf_nick, DATE_FORMAT(fme_creation_date, "%d-%m-%Y %H:%i:%s") AS fme_creation_date,
    22.     IF(fme_creation_date < NOW() - INTERVAL 1 WEEK, NULL, fme_comment) AS fme_comment
    23. FROM forums_topics
    24. LEFT JOIN forums_events ON frt_fme_id = fme_id
    25. LEFT JOIN forums_messages ON frm_id = frt_last_frm_id
    26. LEFT JOIN profiles AS prf ON prf.prf_id = frt_prf_id
    27. LEFT JOIN profiles AS lmp ON lmp.prf_id = frm_prf_id
    28. WHERE frt_for_id = '.(int)$this->forum_id.$where.'
    29. ORDER BY sort_sticky ASC, sort_date DESC LIMIT '.$limit, $database);
    30. $total_records = mysql_result(mysql_query('SELECT COUNT(*) FROM forums_topics WHERE frt_for_id = '.(int)$this->forum_id.$where, $database), 0, 0);
    31. ?>
    PDO идёт лесом сразу.
     
  17. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    если бы я каждый день рисовал ТАКИЕ запросы.. не только не мой моск...
     
  18. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    Для меня это будни, мозг не напрягаю особо.
     
  19. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    сочувствую, ник подходящий ;)
    а почему не на ассамблере?
    рекомендую 10 раз подумать о односложных предложениях и понятной логике, прежде чем такое лепить.
    на крайняк оборачивать в методы, ибо это СТРАШНО.
     
  20. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    а на счет
    принимаю, пришлось приспособица.
     
  21. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Ti
    А SQL процедуры в MSSQL на 2500 строк для выставления счетов за месяц в биллинге большой компании тоже страшно? Это, между прочим, самый правильный подход. Со стороны в базу данных пользователи вообще не имеют доступа к таблицам, только к процедурам. Ими они и оперируют, операции SELECT, UPDATE и.т.д. просто запрещены, только вызов процедур.

    В серьёзных проэктах это нормально. При больших объёмах баз данных (а она у нас уже сейчас 5+ GB, и каждый день растёт на пару сотен мегабайт, есть таблицы где уже по 1.5-2 миллиона записей, а это только начало, будет больше. Уже сейчас SQL сервер обслуживает больше 1500 запросов в секунду, представте сколько их будет если написать 5 запросов а не один, сервер загнёться) выполнить даже 2 запроса вместо одного уже можеть быть медленее чем 1 более сложный, но хорошо оптимизированный запрос. Я уже не говорю про 3-4 и более.
     
  22. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    я ничего не путаю? это форум по php?
     
  23. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Да, PHP. Но PHP программист должен хорошо знать SQL и уметь его применять на полную катушку, а не половина на SQL, половина на PHP. Если вы умеете составлять не сильно сожные запросы да и только - далеко вы не уйдёте. Так что идиальные знания SQL'a необходимы для работы в больших и прибыльных проэктах и компаниях.
     
  24. Ti

    Ti Активный пользователь

    С нами с:
    3 июл 2006
    Сообщения:
    2.378
    Симпатии:
    1
    Адрес:
    d1.ru, Екатеринбург
    глядеть широко, местами вглядываца в даль. xSQL знать хорошо, но фанатеть тоже грань.
     
  25. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Никто о фанатстве и не говорит. Просто в больших системах надо больше пользоваться SQL'om, будет проще и менее тормознуто :p
     
Статус темы:
Закрыта.