Comments 63
Прощу прощения. Вам времени не жалко своего?
+2
В чем проблема-то?
+2
Просто я считаю работу с БД таким образом — просто потерей времени. Есть достаточное количество ORM на PHP, которые действительно способны сократить время разработки.
-10
Бесспорно. Но значит ли это что можно не уметь работать с БД без них. Я вот тоже пользовался возможностями фрейморков и уже забыл как работать с БД напрямую, а тут понадобилось переносить базу данных, где некоторые таблицы сотни мегабайт. Вы можете сказать про сервера с десятками гигабайт оперативки, но в моем случае не было таких серверов, а был средний впс, а делать нужно.
+5
Придет время, когда наравне с обычными таблицами будут здоровенные view'хи. Тогда sql вспоминается на раз и узнается о нем много нового. А составлять запросы, когда через ORM это будет быстрее, секурнее и ООП-шнее — не стоит.
-4
Угу, а потом DBA за голову хватаются, когда видят, что ORM нагенерил.
ORM не отменяет необходимости писать некоторые запросы вручную.
ORM не отменяет необходимости писать некоторые запросы вручную.
0
Много вы DBA знаете в веб-разработке?
Много вы DBA знаете, которые не умеют работать с ORM?
Много ли DBA вы знаете?
Много вы DBA знаете, которые не умеют работать с ORM?
Много ли DBA вы знаете?
0
1. да
2. им пофигу на ОRМ, вообще. DBA сказал, как написать запрос — разработчик пишет, если ОRМ не позволяет, значит, выбросить ОRМ.
3. да
2. им пофигу на ОRМ, вообще. DBA сказал, как написать запрос — разработчик пишет, если ОRМ не позволяет, значит, выбросить ОRМ.
3. да
0
По-вашему, веб-разработка это только сайтики что ли? Мы занимаемся облачным докуменооборотом, там основной клиент — браузер. Хитов дикое количество, без оптимизации запросов не обойтись. И да, у нас есть DBA и не один.
+1
Если статья окажется кому-то полезной, то жалеть будет не о чем. Статей по mysqli не русском совсем не много, внес свой посильный вклад.
+2
По статье видно что труд приложили, но…
а) В начале была затравка про сравнение с PDO, но его так и невидно
б) Сама статья по сути рерайт мануала по php, ни сравнений (даже с mysql), ни особенностей, ни нюансов, ни специфических функций (тех же асинхронных запросов).
в) Код сам по себе тоже любопытен. Получение результата селекта начиная с выполнения запроса — 16 строк кода с комментами и в случае ошибки die, как-то это не очень в плане демонстрации «как надо делать».
а) В начале была затравка про сравнение с PDO, но его так и невидно
б) Сама статья по сути рерайт мануала по php, ни сравнений (даже с mysql), ни особенностей, ни нюансов, ни специфических функций (тех же асинхронных запросов).
в) Код сам по себе тоже любопытен. Получение результата селекта начиная с выполнения запроса — 16 строк кода с комментами и в случае ошибки die, как-то это не очень в плане демонстрации «как надо делать».
+8
а) Извиняюсь, если кого ввел в заблуждение, не хотел, в будущем буду осторожнее
б) Не соглашусь. Я понимаю, что могло сложиться такое впечатление из за справочного стиля изложения. В мануал я заглядывал только для того что бы посмотреть какие примеры там используются. Текст писал исключительно из головы. Нюансы особенности и специфичные функции которые мне показались интересными я осветил, если это не заметно, видимо не получилось.
В) Примеры слабые не спорю. Основной упор делал на текст.
б) Не соглашусь. Я понимаю, что могло сложиться такое впечатление из за справочного стиля изложения. В мануал я заглядывал только для того что бы посмотреть какие примеры там используются. Текст писал исключительно из головы. Нюансы особенности и специфичные функции которые мне показались интересными я осветил, если это не заметно, видимо не получилось.
В) Примеры слабые не спорю. Основной упор делал на текст.
0
Ещё внесу свои 5 рублей в казну — код ужасен. Если вы начинающий — ещё не страшно (пока), но пора смотреть в сторону идеализации кода до удобочитаемого уровня. Тем более, что это примеры. Ваши читатели будут использовать конструкцию с шестью(!!!) «or», а потом их уволят нахрен.
+7
Было бы не плохо, если бы кто нибудь написал алтернативный более правильный красивый код этого фрагмента с 6 OR.
0
Цепочка обязанностей
Такое делается именно через этот паттерн.
Такое делается именно через этот паттерн.
0
Очень примерно:
- class Result
- {
- private $stmt = null;
- private $result = null;
- public function __construct($min, $max)
- {
- $stmt = $mysqli->stmt_init();
- try {
- $this->prepare();
- $this->bind($min, $max);
- $this->execute();
- $this->attachResult();
- $this->store();
- $this->fetch();
- $this->close();
- } catch (Exception $e) {
- Debug.log('Select Error (' . $stmt->errno . ') ' . $stmt->error);
- }
- }
-
- // подготовливаем запрос, там куда будут вствлятся данные отмечаем символом ? (плейсхолдоры)
- private function prepare()
- {
- $this->stmt->prepare("SELECT title FROM sk2_articles WHERE id > ? and id < ?")
- }
-
- // привязываем переменные к плейсхолдорам
- private function bind($min, $max)
- {
- $this->stmt->bind_param('ii', $min, $max);
- }
-
- // отрправляем даные, которые на данный момент находятся в привязанных переменных
- private function execute()
- {
- $this->stmt->execute();
- }
-
- // привязывем переменую для получения в нее результата
- private function attachResult()
- {
- $this->stmt->bind_result($this->result);
- }
-
- // делаем запрос буферизированным,
- // если бы этой строки не было, запрос был бы небуферезированым
- private function store()
- {
- $this->stmt->store_result();
- }
-
- // получение результата в привязанную переменную
- private function fetch()
- {
- $this->stmt->fetch();
- }
-
- private function close()
- {
- $stmt->close();
- }
-
- public function getResult()
- {
- return $this->result;
- }
- }
-
- $id_min = 81;
- $id_max = 88;
- $result = new Result($id_min, $id_max);
- print $result->getResult();
* This source code was highlighted with Source Code Highlighter.
0
Спасибо за пример.
Во время написания статьи думаешь не сколько о применимости кода, сколько об его наглядности и краткости. Ни кто не хочет разбираться в большом коде. К тому же мне кажется любому очевидно, что в статьях подобно этой выкладывают не готовые решения, которые можно использовать в продакшин.
Во время написания статьи думаешь не сколько о применимости кода, сколько об его наглядности и краткости. Ни кто не хочет разбираться в большом коде. К тому же мне кажется любому очевидно, что в статьях подобно этой выкладывают не готовые решения, которые можно использовать в продакшин.
+1
Ну и смысл тянуть эту портянку в демо-статью — показать, что GoF прочитал? Замечания на будущее: комментарии — на английском, в формате phpdoc (а не коменнтариями, как сейчас). И self-described члены класса обычно не требуют description.
+1
Ожидал увидеть асинхронные запросы.
+2
Вы наверное о небуферизированный запросах. Я старался раскрыть тему, что бы было понятно как их делать. С примерами, к сожалению действительно как то плохо. Боялся, что будет слишком объемно, видимо зря.
0
Нет, именно о асинхронных.
0
Можно пример?
0
Пример из мануала:
ru2.php.net/mysqli.poll#refsect1-mysqli.poll-examples
Асинхронные запросы доступны если расширение скомпилировано с использованием mysqlnd (используется по умолчанию начиная с PHP 5.4).
ru2.php.net/mysqli.poll#refsect1-mysqli.poll-examples
Асинхронные запросы доступны если расширение скомпилировано с использованием mysqlnd (используется по умолчанию начиная с PHP 5.4).
+1
Так в чем преимущество в сравнении с PDO?
+5
Про недостаток я написал. Про преимущество ни чего не скажу, так как не работал с PDO.
0
В век серверов по 50 евро с 24 Гб памяти эти недостатки как-то теряются на фоне.
0
Видимо вы не о том недостатке. Я о том, что в MySQLi плейсхолдоры не могут быть именованными, и соответственно мы зависим от порядка их объявления.
+3
Тогда вообще: возьмите на вооружение Doctrine ORM или Propel ORM. Про низкоуровневые слои типа PDO или mysqli — забудьте. Вспоминайте про них только тогда, когда это будет ну очень нужно. Разницы нет, честно.
0
Как только я увидел что у mysqli неименованные плейсхолдеры, это полностью исключило этот бакенд в качестве использования… PDO, только PDO, к тому же позволит максимально легко сменить базу данных в будущем.
0
Значит, закон 94-ФЗ вас не касается. Повезло.
0
real_connect() real_query() real_escape_string()
Я понимаю, разработчики MySQL долбанутые, у них самые часто используемые функции начинаются с «real_».
Я понимаю, разработчики расширения mysql тупо один-в-один скопировали API MySQL со всеми идиотскими префиксами.
Но вот на кой ИКС разработчики MySQLi вытворили то же самое? У разработчиков PHP какая-то болезненная любовь к «безопасным» префиксам?
А если бы разработчики MySQL назвали функции mysql_secure_escape_string_with_support_for_character_encoding, разработчики PHP его точно так же скопировали бы? Так ведь это время не за горами, для MySQL придумают новую версию, старые оставят для обратной совместимости и пометят устаревшими.
-4
Последние годы я писал сайты исключительно на фреймворках, что избавляло меня от работы с БД напрямую. Некоторое время назад начал работу над сайтом на чистом php
Зачем понадобился чистый PHP, к слову?
0
а это нормальный период. Многие через него проходят и не редко есть идея: «Создать свой фреймворк». Ну или подобное что-то.
-3
Жалко денег на дорогой сервер. Сайт приносит мало денег, а посетителей много, хотелось что бы ни чего лишнего небыло, тогда можно обходиться средним vpsом
0
средним vps'ом можно обходиться если правильно продумать кэширование ;)
0
Вот хочет заказчик видеть реальное число просмотров поста в блоге, чтоб на каждое F5 цифра была новая, и запрос к БД уже надо делать. А главное PHP вызывать нужно.
0
(a) чтоб на каждое F5 цифра была новая, и (b) запрос к БД уже надо делать
Из а не следует b. Что мешает обновить счетчик в кеше при регистрации просмотра?
0
Смотря о каком кеше речь идёт. Одно дело о кеше страницы для анонимусов, другое даже для тысячи зареганных пользователей, у каждого из которых своя страница, большая часть из которых могут эту страницу и не открыть. Третье — кеш запроса к БД.
0
О кеше количества просмотров поста в блоге. В данном случае не вижу разницы между анонимусами/зареганными пользователями — один инкремент счетчика в мемкеше/редисе решает вопросы с рил-тайм апдейтами для любого типа пользователей.
0
Это будет кеш запроса к БД, а не кеш страницы. И есть подозрение, что большого выигрыша кеширование в мемкеше запроса вроде
SELECT * FROM posts WHERE id = ?
не даст, поскольку СУБД тоже кешировать умеет.0
MySQL из рук вон плохо кеширует — при любом изменении таблицы сбрасываются кеши всех запросов, в которых эта таблица участвовала, даже если изменилась запись, которая в резалт-сетах не встречалась. Так что память лучше потратить на buffer pool (key cache для MyISAM) и кешировать данные вне базы (разумеется более интеллектуально).
0
Ладно вам уже, у любого решения есть критерий разумной применимости. Если заказчик хочет realtime счетчик и готов за это платить железом — флаг ему в руки =) Если не готов, но может раскошелиться на бОльший срок разработки — аналогично. Флаг в руки, только другой расцветки. Можно хоть аккумулировать эти счетчики в redis и скидывать в БД по времени или кол-ву хитов.
А если заказчик хочет и рыбку съесть и удовольствие получить — то нужен ли вам такой заказчик? ;)
А если заказчик хочет и рыбку съесть и удовольствие получить — то нужен ли вам такой заказчик? ;)
0
Есть ли в MySQLi аналог mysql_pconnect()?
0
А вот про это планировал написать, но забыл. Для создания постоянного подключения необходимо перед именем хоста при создании подключения добавить «p:». Изначально этой возможности в mysqli не было, но с версии PHP 5.3 ее вернули.
0
От статьи ожидал чего-то большего.
+2
И чем это отличается от официальной документации? То же самое другими словами. Никаких собственных мыслей не привнесено.
+1
Кстати забавный аргумент про возможность «легко» перескочить на другую базу, вот сколько не было проектов ну не разу не пригодилось.
И еще один забавный момент — бывают проекты где вся логика зашита в базе, и данные получаются посредством процедур, там вообще пофиг что использовать, хоть ORM, хоть PDO, хоть mysqli, правда, если не изменяет память кто то из последних двух не умеет принимать множественный результат.
И еще один забавный момент — бывают проекты где вся логика зашита в базе, и данные получаются посредством процедур, там вообще пофиг что использовать, хоть ORM, хоть PDO, хоть mysqli, правда, если не изменяет память кто то из последних двух не умеет принимать множественный результат.
0
PDO выйграл.
/**
* @var PDO
*/
$db;
$statement = $db->prepare($sql);
$statement = $db->execute(array($param));
$result = $statement->fetchAll();
// Ещё короче.
$statement = $db->query($sql, array($param));
$result = $statement->fetchAll();
0
Sign up to leave a comment.
MySQLi раскладываем все по полочкам