-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Создал класс (ООП PHP5) для работы с БД MySQL - покритикуйте, похвалите
- Автор темы Volmir
- Дата начала
Вот прямо в полтора раза быстрее? И в полтора раза безопаснее?
И где ж тебе эти цифры сказали, милок?
"пацаны с пхп.су рассказали" - это не "факт". Это называется "бабкины сказки"
Тебе наврали.
Скорость самого расширения никакой роли не играет вообще.
Про безопасность тоже.
сама по себе MySQLI никак безопасности не прибавляет
а если с умом пользоваться, то и та и другая библиотека одинаково безопасны.
вот видишь - ты не можешь привести ни одного конкретного примера, почему надо использовать MySQLI, а лезешь с советами.
Советовать (да ещё таким тоном) надо только то, в чем сам уверен, а не что пацаны на раёне рассказали
Тебе наврали.
Скорость самого расширения никакой роли не играет вообще.
Про безопасность тоже.
сама по себе MySQLI никак безопасности не прибавляет
а если с умом пользоваться, то и та и другая библиотека одинаково безопасны.
вот видишь - ты не можешь привести ни одного конкретного примера, почему надо использовать MySQLI, а лезешь с советами.
Советовать (да ещё таким тоном) надо только то, в чем сам уверен, а не что пацаны на раёне рассказали
malina95
Здесь всем помогают.
Смотри, и тебе я уже помог. Я тебе дал очень простой совет: говорить только о том, что сам точно знаешь, а не о том, что от кого-то услышал.
Главное приходить именно за помощью, а не за тем, чтобы поучить других. Чувствуешь разницу?
В интернете написано чудовищное количество ерунды. Доверять нельзя никому. Мне - можно.
У mysqli есть только одно принципиальное преимущество перед mysql - последнюю лентяи-разработчики не хотят поддерживать и хотят объявить устаревшей.
Это единственная причина, по которой стоит писать свой класс на mysqli. Но даже это не так важно. Если ты работаешь с БД только через свой класс, а не через функции API, то даже когда mysql окончательно запретят, переписать один класс на новые функции можно будет за полчаса.
Здесь всем помогают.
Смотри, и тебе я уже помог. Я тебе дал очень простой совет: говорить только о том, что сам точно знаешь, а не о том, что от кого-то услышал.
Главное приходить именно за помощью, а не за тем, чтобы поучить других. Чувствуешь разницу?
В интернете написано чудовищное количество ерунды. Доверять нельзя никому. Мне - можно.
У mysqli есть только одно принципиальное преимущество перед mysql - последнюю лентяи-разработчики не хотят поддерживать и хотят объявить устаревшей.
Это единственная причина, по которой стоит писать свой класс на mysqli. Но даже это не так важно. Если ты работаешь с БД только через свой класс, а не через функции API, то даже когда mysql окончательно запретят, переписать один класс на новые функции можно будет за полчаса.
Светозар
Новичок
После многочисленного поиска и чтения различных материалов, пришел к выводу, что мне нужен класс по работе с MySQL. Испробовал более 20, что нашел в рунете, 2 - с книги и один пробовал написать сам своими корявыми руками. Результаты плачевные. Хотелось бы посмотреть что получилось у ТС в данной теме на данный момент. В суть обсуждения я начал догонять, только как-то медленно.
Все новые сообщения уехали в отдельную тему, http://phpclub.ru/talk/threads/Сравнение-mysql-ext-и-mysqli.76036/
hell0w0rd
Продвинутый новичок
а что кривовато-то?
Absinthe
жожо
hell0w0rd
1. Она не предоставляет более высокий уровень абстракции над pdo. Отовсюду огрызки этого pdo в ней и торчат.
2. Код плохо пахнет: такое чувство, что его только пишут, но после этого не читают написанное. phpdoc не соответствует коду, объекты их интерфейсам и т.д.
3. Была попытка сделать у них Connection:
ARAM_INT_ARRAY, но в итоге они не осилили, и сделали ее только в executeQuery(), а с обычными prepared statement она не работает.
4. Качество документации не лучше качества кода.
1. Она не предоставляет более высокий уровень абстракции над pdo. Отовсюду огрызки этого pdo в ней и торчат.
2. Код плохо пахнет: такое чувство, что его только пишут, но после этого не читают написанное. phpdoc не соответствует коду, объекты их интерфейсам и т.д.
3. Была попытка сделать у них Connection:
ARAM_INT_ARRAY, но в итоге они не осилили, и сделали ее только в executeQuery(), а с обычными prepared statement она не работает.4. Качество документации не лучше качества кода.
Вурдалак
Продвинутый новичок
Заодно добавлю, что поражает в Doctrine отсутствие автоматического экранирования идентификаторов (имён таблиц/колонок). Там есть список зарезервированных слов для каждой СУБД, есть возможность экранировать идентификатор, но нет — я должен вручную указывать, где нужно экранировать.
Вот, например: http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#sequence-generator — это не будет в Postgres работать, несмотря на то, что пример вроде бы для Postgres и Oracle. Требуется @Table(name=...) указать, ибо User в Postgres — зарезервированное слово.
Вот, например: http://docs.doctrine-project.org/en/2.0.x/reference/basic-mapping.html#sequence-generator — это не будет в Postgres работать, несмотря на то, что пример вроде бы для Postgres и Oracle. Требуется @Table(name=...) указать, ибо User в Postgres — зарезервированное слово.
Absinthe
жожо
Забыл про Propel же.Хорошо, а какие достойные альтернативы?
Но меня гложут смутные сомнения: почему он там мало используем?
Потеснее с ним разберусь в ближайшее время.