Прекращение поддержки расширения MySQL в PHP
1. Studentsov (15.07.2011 / 15:35)Да, вы совершенно правильно прочитали этот заголовок: в прошлые выходные Филип Олсон отправил в список рассылки php-internals предложение о начале постепенного ухода от расширения mysql в будущих версиях php. Это, однако, не означает, что mysql уже не будет в PHP 5.4, но с версии 5.5 уже начнётся работа по обновлению документации и добавлению E_DEPRECATED ошибок к функциям mysql.
В качестве замены текущему нативному расширению предпологается использовать расширение mysqli или PDO, а возможно mysqlnd.
В результате, в будущих версиях PHP5 (начиная с 5.5 или 5.6) вызовы таких функций, как mysql_pconnect, mysql_query и так далее будут пораждать весьма неприятные уведомления E_DEPRECATED, а уже в версии PHP 6 код этих функций будет, скорей всего, полностью удалён из PHP.
Ура, товарищи!
P.S. Отказ идёт не от MySQL в PHP, а от устаревших функций mysql_*, читаем внимательно
2. Sifon (15.07.2011 / 15:39)
не вижу причин для радости.
3. Studentsov (15.07.2011 / 15:43)
Наконец этот набор устаревших небезопасных функций будет удалён
4. Роман (15.07.2011 / 16:13)
Блин, а я только за мускул всерьез взялся... 0.о
5. KingNLO (15.07.2011 / 16:17)
3. Дмитрий, в любом случае в мобильном интернете произойдет переразпредиление мощностей кодеров..
И некоторые уйдут опять на файлы.
6. Studentsov (15.07.2011 / 16:20)
Да не сам mysql сносят, а функции mysql_*
PDO всегда ждёт вас
7. Sifon (15.07.2011 / 16:22)
5. KingNLO, никто на файлы не уйдет. Просто будут искать альтернативу для Mysql. Ты себе представляешь Одноклассники на файлах??
Хотя, лично я не вижу причин отказа от Mysql. Самая быстрая БД из существующих ныне.
8. Studentsov (15.07.2011 / 16:22)
KingNLO (15 Июля 2011 / 16:17)Вряд ли, мощных движков на файлах уже не осталось
3. Дмитрий, в любом случае в мобильном интернете произойдет переразпредиление мощностей кодеров..
И некоторые уйдут опять на файлы.
9. Sifon (15.07.2011 / 16:34)
а PDO? Это ведь не Mysql. Хотя, Mysqli - намного тормознутее самого Mysql....
10. mozzzg (15.07.2011 / 16:40)
ну есть вариант не обновлять версию пыха)
11. Sifon (15.07.2011 / 16:43)
10. Капец Прокофьевич, я только хотел сказать об этом. Если проект написан на фреймворке, используюзем Mysql, то проще не менять версию пыха на новую, чем переписывать проект на другой фреймворк с обновленной версией БД.
12. Studentsov (15.07.2011 / 16:46)
PDO предоставляет одинаковый интерфейс (очень удобный, кстати) сразу к куче СУБД
Добавлено через 02:29 сек.
ну есть вариант не обновлять версию пыха)Ага, и ждать кулхацкеров, использующих уязвимости старых версий PHP.
Насчёт фреймворков - все нормальные фреймворки используют PDO по умолчанию
13. Владислав (15.07.2011 / 16:58)
9. Sifon, мегокодер)
14. Sifon (15.07.2011 / 17:12)
13. byvlad, ну-ну... Если у меня тонны кода на фреймворке, который никто не собирается обновлять, то я манал переписывать эти тонны кода... Разве что со временем.... Но однозначно не в данный момент...
Да, мегокодер
15. Studentsov (15.07.2011 / 17:19)
А что за фреймворк?
16. Sifon (15.07.2011 / 17:22)
я образно
17. Виталий (15.07.2011 / 17:35)
да, гуд все, пацаны
18. DEKSDUR (15.07.2011 / 17:44)
Я лично ничего хорошего в этой новости не вижу
19. Владислав (15.07.2011 / 17:48)
14. Sifon, я не об этом)
mysqli не может быть медленнее чем mysql.
А вообще нужно mysqlnd курить.
20. Саня (15.07.2011 / 17:54)
Блинский. ну ладно переползем на mysqli делов то. ПДО интересно но не нравиться.
21. Саня (15.07.2011 / 18:04)
немного доков по мускули http://phpclub.ru/detail/article/mysqli#part_2_3
Кто еще подкинет желательно на рус буду благодарен
22. ктулху (15.07.2011 / 18:11)
19, это ты с чего такие выводы сделал?
Не может быть медленнее потому что ты его используешь?)
23. Андрей (15.07.2011 / 18:12)
Круто чО) Сотни скриптов из паблика умрут в ошибках)
24. Виталий (15.07.2011 / 18:14)
byvlad (15 Июля 2011 / 17:48)почему именно mysqlnd???
14. Sifon, я не об этом)
mysqli не может быть медленнее чем mysql.
А вообще нужно mysqlnd курить.
Добавлено через 00:52 сек.
надо почитать об mysqlnd, никогда не слышал об этом
25. Дмитрий (15.07.2011 / 18:18)
Жесть...
26. Саня (15.07.2011 / 18:22)
Может опять кодерам работенка найдется ибо 100% найдутся люди которые будут извините за выражение, чесать яйца до последнего, а потом в один момент все умрёт, либо покроется бесчисленными ошибками с обновлением версии пых-пых на сервере...
Тогда то и появится мощный пинок под зад, который заставит кучу народа в панике бегать по форумам выискивая норм кодера, который согласиться переписать весь ***код на совместимость.
Добавлено через 00:41 сек.
юзайте ротор, Вантуз не поленился написать ротор на PDO в свое время, и теперь может только посочувствовать своим менее дальновидным конкурентам.
ДжонЦМС - щевелись))
27. ensteyn-asen (15.07.2011 / 18:26)
26. sanzstez, до 6 версии php еще *** знает сколько времени. до того уже джон 500 выйдет и там все будет заебцом
Добавлено через 02:50 сек.
самый оптимальный вариант - Mysqli
28. Саня (15.07.2011 / 18:32)
27. ensteyn-asen, суть не в том важно.
Всеравно это огромная работа не на один день. Конечно я только за чтобы все осталось на своих местах, но уже стоит позаботиться о переходе на новый уровень и изучении того же мускули или пдо на свой вкус и цвет, ыы.
Чтобы не было в один прекрасный день такого http://upwap.ru/1609827
29. Александр (15.07.2011 / 18:43)
появился очередной повод расширить свои познания.
за час прочел доки разные и пошел переписывать скрипты
30. Studentsov (15.07.2011 / 19:11)
mysqli не оптимальный вариант
PDO более универсальнее
31. Саня (15.07.2011 / 19:15)
Смысл универсальности, я же не собираюсь каждый день с одного типа БД на другой перескакивать... Всеравно давно хотел чем то свеженьким заняться вот и шанс. Я наоборот рад что такая фигня произошла)
32. Владислав (15.07.2011 / 19:17)
22. ShiftBHT, mysqli - mysql improved, improved - улучшенный, в технические особенности не углублялся.
p.s. не нужно говорить что на заборе тоже написано.
33. Саня (15.07.2011 / 19:21)
скоро на форуме опять темы-баталии что лучше пдо или мускули)))
34. ктулху (15.07.2011 / 19:31)
32, тогда уж и ненадо говорить то о чём незнаешь
35. Studentsov (15.07.2011 / 19:33)
ShiftBHT (15 Июля 2011 / 19:31)как будто ты чего-то знаешь
32, тогда уж и ненадо говорить то о чём незнаешь
Добавлено через 00:49 сек.
sanzstez (15 Июля 2011 / 19:15)PDO удобнее с точки зрения обеспечения безопасности
Смысл универсальности, я же не собираюсь каждый день с одного типа БД на другой перескакивать... Всеравно давно хотел чем то свеженьким заняться вот и шанс. Я наоборот рад что такая фигня произошла)
36. Тимофей (15.07.2011 / 19:48)
35. Дмитрий, можешь накинуть мануалов по PDO ? от А до Я
37. Studentsov (15.07.2011 / 19:54)
http://php.net/PDO
накинул)
38. Тимофей (15.07.2011 / 20:03)
Дмитрий (15 Июля 2011 / 19:54)а на русском....
http://php.net/PDO
накинул)
39. Андрей (15.07.2011 / 20:11)
Как можно PDO сравнивать с MySQL? PDO это не бд, а лиш универсальный клиент к разным бд... Както так, не нашёл правельных слов.
40. Studentsov (15.07.2011 / 20:15)
MySQL не БД, а СУБД
41. Андрей (15.07.2011 / 21:00)
На мой взгляд PDO удобней использовать- меньше кода и сразу понятно.
<?php
$pdo=new PDO('mysql:host=localhost;dbname=db','user','password');
$pdo->query('SET character_set_connection=utf-8;' );
$pdo->query('SET character_set_client=utf-8;');
$pdo->query('SET character_set_results=utf-8;');
$res=$pdo->query('SELECT * FROM `test`')->fetchAll(PDO::FETCH_ASSOC);
foreach($res as $data){
echo $data['odin'].','.$data['dva'].','.$data['tri'].'<br />';
}
?>
42. Евгений (15.07.2011 / 21:07)
Это означает, что пабличные скрипты позже работать не будут ?
43. Андрей (15.07.2011 / 21:09)
Ronson (15 Июля 2011 / 21:07)Аха.
Это означает, что пабличные скрипты позже работать не будут ?
44. Евгений (15.07.2011 / 21:12)
43. Барыга Обама, Очень смешно.....
Просто спросил, интересно.... т.к. пхп только учу и пабл скрипты беру за основу...
45. SeregaNervous (15.07.2011 / 21:12)
Мда, сколько же скриптов на mysql_query поляжет
46. Studentsov (15.07.2011 / 21:26)
Барыга Обама (15 Июля 2011 / 21:00)что это за ужас?
На мой взгляд PDO удобней использовать- меньше кода и сразу понятно.
<?php $pdo=new PDO('mysql:host=localhost;dbname=db','user','password'); $pdo->query('SET character_set_connection=utf-8;' ); $pdo->query('SET character_set_client=utf-8;'); $pdo->query('SET character_set_results=utf-8;'); ?>
<?php
$pdo=new PDO('mysql:host=localhost;dbname=db','user','password', array (PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8'));
?>
47. Женек (15.07.2011 / 21:26)
45. SeregaS, пока они поляжут, точнее пока все хостинги обновятся (чтобы не терять клиентов - это будет крайне медленно), то к тому времени твои пра пра правнуки будут писать гостевую гнигу
48. ктулху (15.07.2011 / 21:28)
Чего вы кипишуете? до PHP 6 скрипты будут выдавать лишь уведомления.
а PHP 6 ещё даже не пахнет. и уж точно на него не перейдут моментально. Это ещё как минимум год-два
49. Studentsov (15.07.2011 / 21:39)
примерная дата выпуска уже есть
50. orel (15.07.2011 / 21:46)
Фух я думал не только расширение удалят, хорошо что pdo пользуюсь
Добавлено через 01:11 сек.
Dcms пострадает вместе с johnCms
51. Женек (15.07.2011 / 21:50)
50. orel, наоборот, мб в DCMS чего полудшает
52. orel (16.07.2011 / 09:30)
51. Basters, Возможно но мне кажется как был неформатированный код так он и останется
53. Владислав (16.07.2011 / 13:38)
52. orel, сейчас там трэш)
54. mefistic (16.07.2011 / 16:09)
Тоже мне трагедия, тот же PDO освоить можно за пару дней.
55. ramzes (16.07.2011 / 16:33)
Пофиг, как использовал mysqli так и буду.
Pdo вообще не нравится. Неприятно читать код.
почему то не переношу его на уровне днк
____
Про медленнее бред, где пруф?
56. ктулху (16.07.2011 / 16:41)
55, кто сказал что медленнее? пруф?
57. orel (16.07.2011 / 16:51)
53. byvlad, и что он пишет нормальный код, отформатированный?
58. ramzes (16.07.2011 / 17:14)
56. ShiftBHT,
Sifon (15 Июля 2011 / 16:34)я вот про этого персонажа
Хотя, Mysqli - намного тормознутее самого Mysql....
59. ктулху (16.07.2011 / 17:23)
58, а... сори)
60. Владислав (16.07.2011 / 17:35)
59. ShiftBHT, кстати, http://habrahabr.ru/blogs/php/119294/
Добавлено через 00:33 сек.
57. orel, ты видел что бы я такое написал?????????
61. Михаил (16.07.2011 / 18:04)
sanzstez (15 Июля 2011 / 18:22)Поставят старую версию php и все проблемы решатся
Может опять кодерам работенка найдется ибо 100% найдутся люди которые будут извините за выражение, чесать яйца до последнего, а потом в один момент все умрёт, либо покроется бесчисленными ошибками с обновлением версии пых-пых на сервере...
Тогда то и появится мощный пинок под зад, который заставит кучу народа в панике бегать по форумам выискивая норм кодера, который согласиться переписать весь ***код на совместимость.
Добавлено через 00:41 сек.
юзайте ротор, Вантуз не поленился написать ротор на PDO в свое время, и теперь может только посочувствовать своим менее дальновидным конкурентам.
ДжонЦМС - щевелись))
62. Neformat (16.07.2011 / 18:12)
Тут вон php 5.3.x не часто на шаредхостигах встречается, а Вы панику поднимаете на счет 5.6 в котором поддержки MySQL не будет.
63. Михаил (16.07.2011 / 18:21)
Будет поддержка 5.6, никто ничего не убирает
64. Саня (16.07.2011 / 18:41)
61. Flyd, чо уж тут можно ради совместимости и ereg вернуть и версию пыха 3 накатить заодно врубив глобальные переменные.
Ну не важно, все равно переход будет года 2 идти если не больше...
65. Владислав (16.07.2011 / 19:09)
55. ramzes, +100600
66. Михаил (16.07.2011 / 23:20)
sanzstez (16 Июля 2011 / 18:41)Ради совместимости скриптов с mysql ничего дописывать не придется. Прекратили поддержку означает, что свернули все работы по доработке/исправлению
61. Flyd, чо уж тут можно ради совместимости и ereg вернуть и версию пыха 3 накатить заодно врубив глобальные переменные.
Ну не важно, все равно переход будет года 2 идти если не больше...
67. ramzes (17.07.2011 / 03:02)
обертки есть гуд =)
обертки спасают, ооп в очередной раз выигрывает у процедурки;)
68. Андрей (17.07.2011 / 03:11)
Flyd (16 Июля 2011 / 23:20)Это означает что функции mysql_*() будут вызывать предупреждения, а в будущем и вовсе фатальную ошибку.
Ради совместимости скриптов с mysql ничего дописывать не придется. Прекратили поддержку означает, что свернули все работы по доработке/исправлению
69. delete (17.07.2011 / 03:12)
67. ramzes, в основном)) эт я незнаю что нужно намутить в коде, что б заметить разницу.. что б она бросалась в глаза и бесила неимоверно.
70. smartvbxos7 (17.07.2011 / 04:14)
Проходим по всем похапэ файлам с мускулом и делаем следущие замены:
"mysql_query(" to "mysqli_query($mysqli, "
------------
"mysqli_" to "mysqli_"
+ альтернатива mysql_result()
function mysqli_result($query, $key = 0) {
$row = mysqli_fetch_row($query);
return $row[$key];
}
------------
Коннектимся так:
$mysqli = mysqli_connect('host', 'user', 'pass', 'base', 3306) or die('Error: connect to server!');
mysqli_set_charset($mysqli, 'utf8') or die('Error: set charset!');
а дисконнектимся так mysqli_close($mysqli);
P.S если вы используете mysqli_query в функциях то необходимо зделать global $mysqli; внутри функции.
71. delete (17.07.2011 / 04:25)
а каких нибудь изменений в SQLite не предвидется? MySQLi конечно хорошо, но порой удобней юзать SQLite.
72. smartvbxos7 (17.07.2011 / 05:01)
Added: к 70 посту
replace
"mysqli_real_escape_string(" to "mysqli_real_escape_string($mysqli, "
71, скулита даже не субдб
73. ramzes (17.07.2011 / 05:37)
72. SmartMаn, О_о, а что ж это тода?)))
74. smartvbxos7 (17.07.2011 / 08:38)
73, это встраиваемая библиотека
Добавлено через 03:02 сек.
Хотя я упоролся )
http://ru.m.wikipedia.org/wiki?search=sqlite
75. smartvbxos7 (17.07.2011 / 08:52)
Субдб но не серверный а движок
76. Александр (17.07.2011 / 10:11)
Денис Одинец (17 Июля 2011 / 03:25)в php5.4 его убрали как расширение. Соединили с другим. Я имею ввиду sqlite ниже 3й версии
а каких нибудь изменений в SQLite не предвидется? MySQLi конечно хорошо, но порой удобней юзать SQLite.
77. delete (17.07.2011 / 14:28)
SmartMаn, дык в том то и фишка что встроенная
особенно будит интересна тем у кого хостер додик 
и у него вечно мускул сервер отваливается)) Я уже так пару раз обжигался, по часу сидел мучался, пытался при коннектится или другой случай, по неск.раз на дню теряется соединение с базами.
78. Саня (17.07.2011 / 14:50)
Фигня... скулайт не оправдал моих ожиданий.
Переделать как в посте 70 можно, но это fffuuuu конечно, если уж юзать мускули, то не процедурку.
79. delete (17.07.2011 / 14:56)
78. sanzstez, интересно а что ж подвело в SQLite? Конечно sql запросов бедновато, но для многих проектов, то изобилие что есть у MySQLi ненужно))
80. Саня (17.07.2011 / 14:58)
79. Денис Одинец, скорость работы подвела... Да и для нагруженных проектов не годиться. Для блога, гостевой еще куда не шло...
81. ramzes (17.07.2011 / 16:53)
sqlite пока еще молодой проект, дайте ему время, по факту он не хуже, по крайней мере не на много, мускула.
просто много узких мест в нем пока
82. delete (17.07.2011 / 17:08)
80. sanzstez, а что мешает для каждого пользователя создавать отдельную SQLite базу данных
Для форума другую, для списка пользователей третью и т.д Это даж лучше будет, будут подключатся только те базы, которые нужны в данный момент, а не все сразу Да и безопасность возрастает в разы, если не дай бог где то забыл отфильтровать запрос, то взломать через эту дыру пользователей будет не реально, у них другие базы, не связаные с первой))) Да и удаление пользователя удобней, удалил его базу и все, нет больше его.
83. Саня (17.07.2011 / 17:11)
82. Денис Одинец, + лишний раз перегружать файловую систему скулайтом, постоянным считыванием и записью данных.
Хотя я так гостю и блог прикрутил к мотору года 2 назад....
Печальный опыт визави подтверждает что скулайт пока рановато юзать в средних и крупных проектах
84. delete (17.07.2011 / 17:19)
83. sanzstez, как говорит пословица, не храните все яйца в одной корзине. Мне кажется так лучше, повреждение или взлом любого из модулей, не приведет к повреждению всего сайта
но в общем это на любителя, кто то MySQL юзает, а кто то SQLite. Раз уж существует какая нибудь СУБД, значит это кому то все таки нужно.
85. Саня (17.07.2011 / 17:25)
84. Денис Одинец, что мне кажется сомнительным шагом применение такой архитектуры...
Лучше использовать проверенные решения, скулайт это не тот инструмент, тут даже транзакции не помогут избежать проблем при записи данных в БД. Будет тупить неимоверно, если несколько чел одновременно будут пытаться записать данные в базу!
86. delete (17.07.2011 / 17:31)
85. sanzstez, если сайт миллионик, то да)) а если там меньше 1000, то вероятность одновремменного запроса в одну единицу времени маловероятно
Запись и считывание проходит в десятые доли секунды. Хотя всех особенностей я не знаю, возможно такая структура и неоправдает всего возложенного на нее. Я еще масштабных эксперементов не проводил.
87. Саня (17.07.2011 / 17:38)
Денис Одинец (17 Июля 2011 / 17:31)
Я еще масштабных эксперементов не проводил.
Ну и зря. Результаты неприятно удивят))
+ занимать лишнее место на диске если оно лимитировано?
+ не знаю что за глюк такой, может только у меня такая лажа, но при удалении данных из скулайт базы ее размер не уменьшается что есть странно. Хотя можт бок какой...
88. delete (17.07.2011 / 17:45)
87. sanzstez, в размер квоты диска входит и размер баз на диске мускул сервера, я не думаю что хостеры бесплатно там что то будут хранить, ну а то что размер базы данных при удалении чего либо не особо меняется, так это по сути фрагментация данных в файле,такое бывает и у MySQL баз, эт у любого хостера спроси, приходится постоянно дефрагментировать. Ну а если говорить о SQLite то у нее есть такой запрос как VACUUM, который оптимизирует таблицы, например при удалении чего либо.
89. smartvbxos7 (17.07.2011 / 21:50)
На скуле с записью в дб могут быть лаги т.к надо либо блочить при этом дб или ставить в очередь
90. KOZZ (21.07.2011 / 06:36)
нифига не радует новость конечно. но если это действительно к лучшему - значит ничего не остается нам. программист успешен, если постоянно изучает новые методики и технологии.
ООП еще не изучал ввиду ненадобности, поэтому PDO мне не подходит пока что.
буду делать как в 70 посте, хотя скорее всего и от этого вскоре откажутся.
PHP очень активно развивается в сторону ООП, поэтому нужно развиваться вместе с ним в эту сторону
91. ramzes (21.07.2011 / 14:09)
eGo ушел в реал (21 Июля 2011 / 06:36)буду делать как в 70 посте,не занимайся фигней.
осваивай ооп, там проще не куда (конкретно с классом мускули)
92. KOZZ (21.07.2011 / 14:12)
91. ramzes, да я пытался как - то почитывать мануалы по ООП - не очень все это в голове укладывается, подход к программированию другой немного, оформление, синтаксис ... раньше как - то все легко и просто давалось
меня не mysqli пугает, а именно ООП.
когда кстати релиз этой самой версии PHP с урезанными mysql функциями?
93. ramzes (21.07.2011 / 14:14)
musqli_query($query, $link); => $link->query($query);
ни чего сложного;)
94. KOZZ (21.07.2011 / 14:16)
93. ramzes, да там еще какие - то prepare(), exec(), сами эти "->" отталкивают
мне бы на несколько дней в мануалы по ООП закопаться с головой
95. ramzes (21.07.2011 / 14:20)
можно и без них. по мере необходимости и их освоить
это шаблоны запросов
96. KOZZ (21.07.2011 / 14:56)
95. ramzes, а как выглядит аналог mysql_result() на mysqli?
97. ramzes (21.07.2011 / 15:00)
$return = $sql->real_query($q)->fetch_row();
echo $return[0];
98. delete (21.07.2011 / 15:00)
96. eGo ушел в реал, по одной функции бушь спрашивать?
http://php.net/manual/ru/book.mysqli.php
99. KOZZ (21.07.2011 / 15:02)
97. ramzes, %)
100. ramzes (21.07.2011 / 15:06)
98. Денис Одинец, http://www.php.su/functions/?cat=mysqli
русскей изыг предпачтительние
Добавлено через 00:36 сек.
99. eGo ушел в реал, я просто делаю так
function count(){
$return = $this->fetch_row();
return $return[0];
}
101. Виталий (21.07.2011 / 21:01)
Мне понравилась новость.
1.Все публичные скрипты вскором времени перестанут работать.
2.Движение в сторону ООП.
3.Будет больше попыт все таки на професионалов.
До меня ето уже писали, но я хотел бы подчеркнуть
102. ramzes (21.07.2011 / 21:22)
Не так страшен
103. Виталий (21.07.2011 / 23:28)
я раньше думал зачем ету хрень придумали, но когда ознакомился, то понравилось! =) если в веб программировании ещё можно обходиться без него, то в разроботке ПО никак...
(ИМХО)
104. smartvbxos7 (22.07.2011 / 06:47)
Я не юзаю ООП там где оно не нужно, т.к уверен что процедурный подход использует меньше ресурсов.
105. Петр (22.07.2011 / 07:06)
Скорее всего, будет такая же ситуация, как с register globals... Насчет ООП - можно и mysql_* функции обернуть в него, и наоборот написать какие-нибудь алиасы для методов mysqli. Хотя, в целом, нехорошо - php, как мультипарадигменный язык, должен иметь и функции, и объекты.
106. ramzes (22.07.2011 / 09:25)
105. Im-ieee, musqli же имеет и процедурный подход, можно не дописывать ни чего.
107. Петр (22.07.2011 / 11:34)
106. ramzes, блин, только сейчас заметил - всегда использовал объекты(. Ну, в этом случае, вообще разницы никакой, похоже, что достаточно пройтись replace'ом по всем файлам и забыть.
108. KOZZ (22.07.2011 / 13:33)
так, народ, а создавая базы в mysqli я уже не смогу управлять ими через phpmyadmin , так ведь получается?
109. ramzes (22.07.2011 / 13:41)
почему это? mysqli это обновленный mysql
бд одни и те же
110. ктулху (22.07.2011 / 13:47)
Более того, PMA умеет юзать mysqli вместо mysql
111. KOZZ (22.07.2011 / 13:51)
110. ShiftBHT, сорри за тупые вопросы, но как его заставить работать с mysqli ?
112. ктулху (22.07.2011 / 14:02)
111, после того как распаковал скрипт PMA, зайди в настройки (/setup)
Там в настройках точно есть.
в конфиге параметр
$cfg['Servers'][$i]['extension'] = 'mysqli';
113. KOZZ (22.07.2011 / 14:04)
112. ShiftBHT, а на денвере например как это осуществить?
114. Тимофей (22.07.2011 / 14:05)
eGo ушел в реал (22 Июля 2011 / 14:04)тоже интересен вопрос
112. ShiftBHT, а на денвере например как это осуществить?
115. ктулху (22.07.2011 / 14:08)
Ну блин, найдите где там PMA стоит, в конфиге (config.inc.php) добавьте строку которую я дал выше (смотрите чтоб небыло аналогичной), и всё.
116. delete (22.07.2011 / 14:13)
удалено
117. Тимофей (22.07.2011 / 14:18)
ShiftBHT (22 Июля 2011 / 14:08)я не нашел что то ...
Ну блин, найдите где там PMA стоит, в конфиге (config.inc.php) добавьте строку которую я дал выше (смотрите чтоб небыло аналогичной), и всё.
118. KOZZ (22.07.2011 / 14:18)
ну вот, ок, нашел файл
C:\WebServers\home\localhost\www\Tools\phpmyadmin\config.inc.php
изменил ту строку.
перезагрузил денвер, все ок, в PMA появилось: PHP расширение: mysqli
Спасибо, +1
119. ктулху (22.07.2011 / 14:19)
118, анриал. в БД ничего нигде не меняется.
120. KOZZ (22.07.2011 / 14:20)
119. ShiftBHT, это все моя невнимательность, все правильно ты сказал
121. ктулху (22.07.2011 / 14:21)
117, ищи.
120, не за что)
122. KOZZ (22.07.2011 / 14:22)
117. Gamermania,
C:\WebServers\home\localhost\www\Tools\phpmyadmin\config.inc.php
123. Тимофей (22.07.2011 / 14:22)
eGo ушел в реал (22 Июля 2011 / 14:22)я уже увидил
117. Gamermania,
спасиб
124. 3DwEp (22.07.2011 / 17:34)
мда.. 2012 близиться..
125. KOZZ (22.07.2011 / 22:23)
В общем на первое время сменил названия функций с mysql_* на mysqli_*, сделал пользовательскую функцию mysqli_result (аналог mysql_result), и забыл в принципе.
дальше по мере изучения буду продвигаться, пока что этого достаточно
126. Тимофей (22.07.2011 / 22:33)
eGo ушел в реал (22 Июля 2011 / 22:23)разве все так легко?
В общем на первое время сменил названия функций с mysql_* на mysqli_*, сделал пользовательскую функцию mysqli_result (аналог mysql_result), и забыл в принципе.
дальше по мере изучения буду продвигаться, пока что этого достаточно
127. Саня (22.07.2011 / 22:58)
Gamermania (22 Июля 2011 / 22:33)ну не предпочтительный вариант, но сойдет.
разве все так легко?
128. ramzes (22.07.2011 / 23:39)
127. sanzstez, чем это не предпочтительный то?
129. Саня (23.07.2011 / 00:47)
ramzes (22 Июля 2011 / 23:39)Не надо так с вызовом отвечать, будто бы я враг народа.
127. sanzstez, чем это не предпочтительный то?
тем что лучше написать один класс для работы с бд и не париться, чем заменять в каждом файле названия ф-ций каждый раз когда припрет. А то так и получаются костыли.
А то многие осознанно не хотят изучать ооп ссылаясь на сложность, усложняя тем самым себе разработку приложения.
Для кого как конечно. Делайте как хотите , это не мои проблемы.
130. ramzes (23.07.2011 / 01:25)
129. sanzstez, просто ты написал утверждение а доводов не привел.
я конечно тоже предпочитаю собственную ооп обертку, но это дело вкуса, так не лучше и не хуже.
function mysql_query($q){
return mysqli_query($q);
}
Ни чем не хуже чем подгонка класса под новые обстоятельства
131. Саня (23.07.2011 / 01:26)
130. ramzes, ну согласись же что это классический костыль.
132. ramzes (23.07.2011 / 02:38)
Такая же обертка, только процедурка.
я не спорю, ооп в этом плане удобнее,сам его предпочитаю,
но еще раз повторюсь, кому что нравится, это ни как на работе скрипта не отразится
133. KOZZ (23.07.2011 / 08:43)
ну я же говорю, это на первое время, потом все равно на ооп переходить придется так или иначе. удобнее с ним, красивее даже
по мере осваивания перейду
134. KOZZ (23.07.2011 / 09:00)
А как вот например на хостингах заставить phpmyadmin работать с mysqli ?
135. ramzes (23.07.2011 / 10:18)
я наверное чего то не понимаю, что значит "работать с mysqli"?
136. ктулху (23.07.2011 / 11:37)
134, а смысл? с базами будет работать точно так же. никакие форматы не меняются же. пущай работает как есть)
137. Vizor (23.07.2011 / 11:52)
134, он и так работает
138. KOZZ (23.07.2011 / 13:07)
вы меня не так поняли наверное.
ну вот на денвере мне пришлось менять строчку с расширением с mysql на mysqli, а на хосте как с этим дела обстоят?
139. KOZZ (23.07.2011 / 14:12)
139. ZiGR, так не будет же он для меня одного делать mysqli )) или там можно персонально настроить?
140. ктулху (23.07.2011 / 14:15)
140, нет, нельзя. но это ни на что не влияет. Работа с БД остаётся такой же. меняется только драйвер.Никто и не заметит что в PMA вместо mysql стало mysqli.
141. ramzes (23.07.2011 / 14:44)
блин, обьясните мне серому, зачем это надо?
142. KOZZ (23.07.2011 / 15:05)
144. ramzes, да просто я думал нужно что то дополнительно настраивать на хосте чтобы с mysqli работать
шифт спасибо,теперь ясно
143. delete (23.07.2011 / 15:11)
все уже придумано до нас ;)
144. ramzes (23.07.2011 / 15:11)
145. eGo, да не надо ни чего
сервер то все тот же, это просто интерфейс обновленный.
я то думал, упустил чего
145. Sep (24.07.2011 / 12:07)
А в чем собственно разница синтаксиса муsql и myspli?
146. ramzes (24.07.2011 / 12:11)
А зайти на пхп.су и глянуть вера не позволяет?
147. Sep (24.07.2011 / 12:55)
149. ramzes, хочется конкретного ответа от знающего человека
148. ramzes (24.07.2011 / 13:21)
150. IceMan, синтаксис для всех одинаков, знающий, не знающий. Без разницы кто тебе скажет, он от этого не изменится
Сами запросы не отличаются, отличаются функции
149. Максим (02.08.2011 / 07:09)
Я фигею) че так бояться такого перехода? если есть мозг или хотябы часть его работает, то можно переписать целый двиг легко. я тут както зарубежный форум переводил на мускули, так там туева хуча запросов, справился за 30-40 минут... и пока эти ф-и запретят, пока версии пыха в мажоре подымуться пройдет ооочень много времени. знаете, я открою вам глаза, ведь скоро уже 2012 год, год кона света. так че ща париться, все равно наши коды уже никому ненужны будуть...
150. KOZZ (02.08.2011 / 08:27)
действительно, бояться нечего
это вынужденный стимул к развитию так сказать
151. Atmas (02.08.2011 / 14:16)
Уважаемые, скажите, а есть ли выигрыш (разница в производительности) между mysqli в виде ОО и процедурном?
То вот, терзают смутные сомнения)))
ramzes, а ты в каком стиле используешь?
152. XoPyC (02.08.2011 / 14:17)
154. Atmas, доля правды да есть)
153. Андрей (02.08.2011 / 18:24)
154# ну если ты собрался писать супер мега-гига проект с миллионом пользователей то, наверное, разница есть. Тут нужно у разработчиков php спросить.
154. ramzes (02.08.2011 / 19:06)
154. Atmas, я ооп, мне просто так привычнее, свой класс легче модифицировать
а разницы я как то не замечал, по моему ооп немного медленнее должен быть
155. KOZZ (02.08.2011 / 22:09)
ZiGR (3 Августа 2011 / 02:01)wtf?
154. Atmas, я использую ООП (весь двиг процедурный)
процедурный подход это процедурный, объектно - ориентированный это объектно - ориентированный
156. Саня (03.08.2011 / 01:32)
ооп стиль в первую очередь понятнее. различие в скорости выполнения в сравнении с процедурным мизерные. Тем более никто вам не мешает взять дедик или вдс с любыми параметрами железа, если собираетесь строить крупный проект.
Надеюсь хосты "за 5 руб все анлим" уже издохли?
157. ramzes (03.08.2011 / 01:47)
160. sanzstez, если скрипт тормозит то это не от ооп точно))
мне тоже кажется что разница минимальна
158. Atmas (03.08.2011 / 02:16)
Такс, идем дальше
Многие утверждают что PDO будет побыстрее mysqli. Есть ли подтверждения? Или только ничем не обоснованные домыслы?
159. Саня (03.08.2011 / 02:19)
Что-то все так на скорости помешаны... наверное у всех свой фейсбук не меньше
Вот тебе тема если не любишь юзать поиск
http://visavi.net/forum/topic.php?tid=9673&
у ПДО и мускули нет уж такой огромной разницы в скорости работы
160. delete (03.08.2011 / 02:23)
162. Atmas, ну что значит быстрее)) Быстрее работают те функции у которых меньше разных плюшек. Например если идет просто запись и просто считывание, в один поток с блокировкой. А если в неск.потоков, без блокировок, с кучей проверок и т.д эт естественно будит медленней. Ибо одна операция выполняется быстрее чем 10
вот и весь секрет. Само по себе, даж при гениальном методе обработки данных не будит вдруг ускорятся)
161. ramzes (03.08.2011 / 02:34)
164. Денис Одинец, он вообще о другом спрашивал.
162. delete (03.08.2011 / 02:46)
165. ramzes, ну я ему вообще говорю, не конкретно о том о чем он спрашивал
зачем мерять скорость, когда можно посмотреть как оно работает. Эт не только СУБД касается, а так же всех языком программирования и их обверток типа php. Просто я когда хочу понять, что нужно использовать оптимально. Беру и открываю мануал, по конкретной функции. Если там сказанно что она по мимо нужной нам операции, еще чем то занимается в этож время. Естественно она будит медленней, чем её собрат выполняющий всего одну, нужную нам операцию.
163. Петр (03.08.2011 / 05:36)
Вообще, если заботишься о скорости, можно просто прогнать код через какой-нибудь обфускатор.
164. Atmas (03.08.2011 / 10:59)
sanzstez (3 Августа 2011 / 02:19)Ну сарказм тут не уместен, у каждого свои тараканы)
наверное у всех свой фейсбук не меньше
Вот тебе тема если не любишь юзать поиск
http://visavi.net/forum/topic.php?tid=9673&
Вот я особой разницы между ними (в том числе "интерфейсом") не увидел, поэтому решил больше узнать о них...
Если б вызвало сразу отвращение, то определился, а так больше копаю...
За ссыль спасибо, не приучился тут к поиску)))
Денис Одинец, это понятно, но как уже говорилось, я не об этом.
URL: https://visavi.net/topics/23268