Coggeshall J. / Коггзолл Дж. - PHP 5 Unleashed / PHP 5. Полное руководство [2006, PDF, RUS]

PHP 5. Полное руководство.
Год выпуска: 2006
Автор: Джон Коггзолл
Жанр: Программирование
Издательство: Sams Publishing
ISBN: 5-8459-0953-8
Формат: PDF
Качество: Отсканированные страницы
Количество страниц: 749
Описание: Книга известного профессионала в области разработки Web-приложений посвящена пятой версии самого популярного в настоящее время языка написания сценариев для сервера - PHP 5. Этот язык позволяет разрабатывать высокопроизводительные Web-сайты любого масштаба и любой категории сложности. В книге подробно рассматриваются такие вопросы, как базовые синтаксические конструкции языка, объектно-ориентированное программирование на PHP, работа с базами данных и графическими изображениями, а также построение Wap-содержимого. Большое внимание уделяется эффективным решениям типовых практических задач, среди которых - аутентификация посетителей, шифрование данных, использование сеансов, обработка ошибок, работа с электронной почтой.
Книга расчитана на разработчиков разной квалификации, а также может быть полезна для студентов и преподавателей соответствующих специальностей.

Надо пару скринов добавить

Скачал, посмотрел. Уже было в раздаче http://bt.rutr.life/announce.php?uk=X8ObmL1JiV&; получше качеством и с листингами кодов.

******************************
---
От модератора:
Транслит
Правила
Пишите на русском языке!
pickap
https://rutr.life/forum/viewtopic.php?t=373656

Лично мне показалось, что сама книга какая-то косорылая...
Больше понравилась эта - Энди Гутманс, Стиг Баккен, Дерик Ретанс - PHP 5. Профессиональное программирование.
А вообще, что именно лучше всего читать на эту тему?

качество отстойное, как такое можно читать?!!!
после первой страницы глаза уже в кучу, нефиг говно такое выкладывать!

"и какчество и коликчество... Не, конечно, есть, кое-что есть, но - не то, нет, не то..." (с)

книга - гадость...
все быстро и поверхностно как-то, перевод кривой
хорошая книга(от создателей транслятора PHP):
"PHP 5. Профессиональное программирование"
Автор: Энди Гутманс, Стиг Баккен, Дерик Ретанс

Мне тоже не понравилось.
Качество скана - полное говно.
Материал даётся по верхам, да и морально материал устаревший слишком уж.
В 2013 году стоит почитать другие книги.

Я не считаю себя PHP гуру, хотя и программирую на этом ЯП с 2005 года. Ранее уже публиковал свой отзыв на книгу Робина Никсона "Создаём динамические сайты" и продолжаю читать другие учебники для расширения своего кругозора, закрытия белых пятен и прочего. К сожалению, хочу отметить, что большинство книг содержат очень большое количество не просто устаревшего материала, а и фактических ошибок. Потому я собрал подборку "косяков" этой книги и публикую её здесь, чтобы не потерялась. Надеюсь, будущие читатели этой книги воспримут критику адекватно.
Страница 27, откуда-то автору приснился метод объявления переменных при помощи ключевого слова var. Я, конечно, начал знакомиться с PHP уже с пятой версии и о тонкостях работы четвёртой и тем более третьей не знаком, но думаю, что даже в 2006 году вспоминать о такой древности не стоило. В 2013 - подавно.
Страница 29 - новый прикол, оказывается, восьмеричное число должно начинаться с буквы О? Или это переводчики намудрили?
Страница 30 - в описании работы со строками пропущен кусок, в котором поясняется, как указывать в разбираемых строках сложные объекты - массивы, объекты, а также тонкости использования фигурных скобок при таких операциях (уточнение появляется на 69 странице, при рассмотрении массивов, но лучше было его продублировать. Также, при разработке класса для отправки почты по стандарту MIME, это приём используется без пояснений). Также полностью отсутствует описание стандартов HereDoc, NowDoc, они хоть и редко, но встречаются.
Страница 44 - директива global указывает, что надо использовать не локальную переменную с таким именем, а глобальную. Переменная может быть создана и до того, как произойдёт вход в функцию (мало того, обычно так и есть).
На странице 48 автор наивно предлагает давать собственным библиотекам расширения .inc. Сразу стоит пояснить, что так делать крайне неосмотрительно - если такая библиотека окажется внутри каталога, доступного из веба, а пользователю станет известен её урл, то он сможет просмотреть её исходный код, что почти всегда нежелательно. Нет, я не против, есть метод включения интерпретации файлов .inc для PHP, но это - лишние телодвижения, которые в общем то нафиг не нужны.
Страница 51. Автор наивно полагает, что из функции нельзя вернуть два и более значения. Конечно, это неверно, ведь функция может вернуть массив, а это уже сколько угодно значений. А использование адской (как по мне) конструкции
list($a,$b)=func();
где
function func(){return array(1,2);}
наглядно это демонстрирует.
Страница 68, автор называет массивы одной из самых мощных структур данных, уточняя, что в PHP их всего две. Или автор считает массивы мощнее объектов?
Страница 70 указан только вариант объявления массива как array(), но в PHP 5.4 появился вариант [], который также стоит рассмотреть, несмотря на его избыточность и нечитаемость (сугубо ИМХО. Мне вот паскалевские begin...end нравятся больше, чем сишные скобочки. Пусть и печатать их дольше, но зато язык выглядит человечнее. Будь моя воля - я бы закрывал if не простым end, а endif, case - endcase и так далее... впрочем, оффтоп).
На странице 77 при рассмотрении инициализации массивов, допущена грубейшая ошибка - переменная $subarray не инициализирована. Теоретически, ваш скрипт может работать в условиях включённой register_globals, а потому - любая переменная обязательно должна инициализироваться. Об этом надо долбить всем новичкам постоянно по пять раз на день, аки отче наш.
На странице 71 автор предлагает итерироватся (блин, косое слово... но слово «проходить» мне тоже не нравится) по массивам с помощью простого for. И это при том, что две страницы назад он писал, что нумерация массивов может быть непоследовательной. Такой код - одна из худших вещей, которые можно посоветовать новичку.
До страницы 76 так и не рассмотрен второй правильный вариант итерации по массивам - функция each.
Страница 77, автор не устаёт давать вредные советы. Функция srand должна вызываться в скрипте ноль (если случайные числа вовсе не используются), или один раз (если используются), но никогда - больше, в противном случае, генерироваться будут уже не случайные числа.
Страница 78 - запас напалма, которым жжот аффтар нескончаем. Он уверяет, что вместо логичной структуры
$pets=array(
array('name'=>'Бим','weight'=>9,'owner'=>'Иванов','type'=>'Собака'),
);
гораздо удобнее использоваться непонятное месиво, которое потом ещё нужно разбить по отдельным массивам! Мой вариант легко сортируется одним вызовом:
usort($pets, function($a,$b){
if($a['name']<$b['name'])return -1;
if($a['name']>$b['name'])return 1;
return 0;
});
правда, некоторые редакторы от анонимок тупят, так что я их стараюсь избегать.
В главе про регулярные выражения полностью пропущено указание о том, что для работы в многобайтовом окружении (русский язык) требуется использовать mb_preg_***, автору это простительно, на английском таких проблем нет, а вот переводчик должен был отметить. Технические тексты должен переводить технически грамотный человек.
Ну и в конце главы, в резюме, автор делает совершенно неверный вывод о том, что регулярные выражения стоит использовать реже, стараясь обходиться строковыми операциями. Честное пионерское, когда мне приходится разгребать завалы собственного кода, я предпочитаю поменять сколь-либо сложную логику парсинга данных на строковых операциях на аналог на регулярках. Несмотря ни на что, код становится понятнее, а это главное. Хотя злоупотреблять тоже не следует.
Страница 106, желательно было рассмотреть также тег optgroup, позволяющий группировать элементы списка и делающий их более приятными для восприятия.
Страница 110 - автор рекомендует для повышения безопасности вместо register_globals использовать import_request_variables. Хочется сразу поинтересоваться - это диверсия такая? Вроде, книга называется не "Вредные советы", а автор - не Григорий Остёр. Как первый, так и второй варианты никогда не должны использоваться, в достаточно чуть-чуть не досмотреть, чтобы получить инъекцию в свой код.
Страница 114. Автор не проверяет имена констант. Там должно быть UPLOAD_ERR_NO_FILE (пропущено одно подчёркивание). Куча пропущенных констант... впрочем, понятно, что учебник надо читать только вместе с фирменной документацией.
Глава "Целостность данных формы", на мой взгляд, сильно переусложнена. Действительно, если мы защищаем форму подписью, то зачем хранить в этой же форме перечень защищаемых полей? Давайте сделаем перечень защищаемых полей в виде массива и просто посчитаем сумму всех полученных из формы полей, которые есть в этом массиве! Array_intersect поможет выбрать только защищаемые поля, array_reduce - свести данные к одной строке (например, просто произведя строковое сложение всех данных). Можно также использовать serialize, или var_export. Сравнить подпись из формы и сгенерированную подпись. Всё! Десять строчек!
Точно также перегружен метод проверки полей на непустоту. Да, надо указывать пользователю на то, какие поля неверно заполнены и какие - не заполнены, но должны. Тем не менее, в любом случае сервер должен знать, какие пришедшие ему данные и как должны быть заполнены. Я обычно создаю единый массив правил, из которого функциями-хелперами (на самом деле, класс-хелпером на базе кохановского Form) строю HTML код формы (при этом часть валидаций может быть реализована штатными средствами HTML, часть - средствами jQuery и AJAX, часть не реализована вовсе) и с использованием точно того же конфигурационного массива я проверяю принятые данные. И даже при этом методе, показавшем удобство и гибкость (массив настроек можно убрать в модель, где ему самое место), я не считаю данный метод идеальным. Автор же свой явно чрезмерно неповоротливый метод считает идеальным.
На странице 144, при объяснении работы с кукишами, автору следовало бы упомянуть, что вызов setcookie, равно как и любой другой метод установки кукиша, никак не влияет на суперглобальный массив $_COOKIE. Может быть, для всех это и очевидно, но я нередко допускаю такую ошибку, устанавливая кукиш, влияющий на отображение страницы, а затем в той же сессии пытаясь использовать его значение. Также стоит отметить, что уничтожение сессии командой session_destroy() не уничтожает переменные в $_SESSION, как это ни странно и их надо уничтожить вручную. Ну и напоследок - а стоит ли корячиться и описывать, как работает передача идентификатора сессии в 2006 году? Ради полутора клиентов, отключивших кукиши усложнять код? ИМХО, не стоит.
Страница 163 - способность Smarty компилировать шаблоны в PHP код выдаётся за достижение... лучше бы автор привёл пример шаблонизаторов, которые так НЕ делают. Это как указывать на то, что в наушниках применяются неодимовые магниты... других там просто не применяется.
Страница 164 - ошибка, каталог templates_c НЕ должен находиться в дереве веб документов.
Страница 179 - задача переменной read_hidden диаметрально противоположная.
Страница 185. Автор рассматривает PEAR. Честно, не помню, когда начал своё победоносное шествие composer, но как минимум его рассмотреть надо. Оправданием автору может служить только факт, что на момент написания книги, Композер был ещё только в зачаточном состоянии, тогда как pear вполне заматерел.
На странице 254 автор уверяет читателя, что использовать файл, имя которого начинается с точки в ОС Windows нельзя! Уверяю автора, что это утверждение если и имело место быть, то только лет пятнадцать назад - даже на флешках с системой FAT32 можно без труда создавать такие файлы. Или автор винду последний раз в двадцатом веке видел?
Ну а на странице 261 автор рекомендует использовать функцию crypt, которая вымерла сразу вслед за динозаврами. Более современные авторы используют MD5 или SHA1.
Также промолчу про использование устаревшего метода доступа к базам данных через MySQL, как минимум, MySQLi, а лучше сразу PDO.
Страница 271 и использование полного перебора для поиска нужной записи в базе данных - это не просто звиздец... я даже не могу подобрать подходящего слова! Секция where - не для нас! Это же СПАРТААААА!!!!1111
В 13 главе автор зачем-то начинает вспоминать про PHP4. Непонятно совершенно, зачем - похоронили, и понь с ним. Только изложение запутывать.
Страница 319 - где-то переведено Caught, где-то нет.
Страница 326 - "Только что принятый администратор может предъявить настолько строгие требования..." - правильнее сформулировать: "А только что пришедший на работу идиот может натворить такого..."
На странице 364 до сих пор используются простыни из require_once, описать один раз, что за зверь - классовый автозагрузчик и с чем его едят - это не наш метод. Особенно с учётом того, что все современные фреймворки используют ТОЛЬКО класслоадер (в подавляющем большинстве случаев сгенерированный Composer), так что рассмотреть этот метод НАДО.
Страница 370 - фактическая ошибка, base64_encode НЕ шифрует, а КОДИРУЕТ данные. Это - две очень большие разницы.

Глава 19 посвящена WAP. Простите, а он что, ещё где-то используется? Все телефоны прекрасно научились отображать обычные веб страницы, извращения не требуются.
Страница 430 - почему написано, что readfile надо использовать для версий до php 4.3? Кажется, всё совсем наоборот. В том же месте автору стоило бы не позориться с его доморощенными вызовами php скриптов с параметрами, а рассказать про mod_rewrite и как можно картинку с адресом http://server.ru/picture.jpg на лету генерировать скриптом.
Страница 444 - среди функций записи в файл пропущена очень полезная fprintf.
Страница 448 - автор продолжает давать вредные советы. Использование счётчика в файле - нонсенс. Если уж очень хочется, то нужно пользовать flock. Помните только, что это - осезависимая функция.
Страница 516 - чтобы справиться с на самом деле большими объёмами, большинство уже отказались от реляционных баз и перешли на NoSQL решения, которые пусть по надёжности и значительно уступают традиционным SQL решениям, зато отлично масштабируются (по территориальному, временному и прочим принципам), быстрее в чтении (никаких джойнов - всё хранится в одной таблице), правда, медленнее в обновлении и крайне медленны в удалении (заметьте: ни в одной социальной сети НЕТ кнопки "Удалить аккаунт", максимум, что вы сможете сделать - удалить всех "друзей" и отметить всю информацию как приватную, после чего отвязать аккаунт от телефона, поменять пароль и забыть его). Об этих решениях, например MongoDB, можно почитать в интернете.
Страница 517 - автор не скупится на вредные советы, называя записи строчками, а поля - столбцами. Новичкам надо говорить сразу правильную терминологию, а то потом она никогда не привьётся. На первой странице ещё можно позволить себе расшифровку с скобках: "Каждая таблица состоит из записей (строк). Каждая запись состоит из одного или нескольких полей (столбцов)."
То, что автор путает СУБД и собственно базу данных - это уже нормальное и привычное явление и меня оно уже не смущает.
Страница 519 - и вновь автор пособия начинает учить ненужному. Утилита MySQL командной строки почти нигде не используется. Рассмотрел бы лучше phpMyAdmin, он используется повсеместно, а
SQL там точно такой же.
Страница 520 - базами данных поставщики услуг интернет (более правильно написать - провайдеры) не занимаются, это работа хостера. Хостер и провайдер могут быть одним лицом/фирмой, но это скорее исключение, чем правило.
Страница 521 - никакими типами автор, кажется, не пользовался. Int zerofill - число дополняется нулями слева до максимальной размерности. Varchar может являться регистрозависимым и без указания binary, у каждой таблицы (а также у базы данных в целом) есть такой параметр - кодовая страница. Например, кодовая страница utf8_general_ci делает поля нечувствительными к регистру, а, например, utf8_bin - напротив, чувствительными. Другими типами не пользовался лично, врать не буду, нужно проверять.
Страница 524 - опять плохой совет. Insert into (field1, field2, field3) values('value 1', 'value 2', 'value 3') - полная форма должна использоваться всегда. Конечно, для реальной работы, стоит использовать либо самопальные хелперы, либо ORM.
Сразу же хочется отметить непредусмотрительность автора. Первичный ключ - крайне важная штука для реляционных баз данных. А про него так ничего и не сказано!
Страница 527 - при рассмотрении оператора order by следует обязательно отметить, что это почти обязательный оператор, потому что если его не указать, то при каждом следующем запуске порядок записей может отличаться. А может и нет. На рабочей машине я чаще получал разные результаты, а вот на машине для разработки - почти всегда идентичные и отсортированные по порядку добавления записи в базу. Вероятно, именно из-за этого эффекта у большинства авторов и складывается пагубное ощущение постоянности возвращаемого результата.
Страница 528 - упоминая про фильтр regexpr стоит отметить, что эта операция работает существенно медленнее простого like и должна использоваться только если нет другого выбора.
Страница 546 - также, файл connect.inc можно просто назвать connect.php - и всё, никто данные подключения не узнает.
Также, примерно в том же месте - автор несколько раз открывает и закрывает соединение с базой. Сильно напоминает анекдот: "Выльем воду из чайника, чем сведём задачу к предыдущей".
Страница 555 - также к false сводится числовой 0 и пустая строка. Разработчикам PHP - великий респект! Операция строгого сравнения должна использоваться почти повсеместно, тогда как места для "обычного" сравнения почти не останется.
Страница 556 - очень желательно привести пример одновременной привязки как в запросе, так и в результате. То есть запрос должен выглядеть как select name, surname from names where name like ?
На той же странице, про тип InnoDB. Стоит обратить внимание некоторых горе-пользователей (есть такие, из практики), что смена типа таблицы - не простая формальность. Надеюсь, что все помнят, что резервные копии должны делаться и тот, кто их не делает, будет гореть в аду вечно. Так вот, некоторые (на самом деле, многие, но давайте не будем о грустном) в качестве резервной копии просто копируют каталог с базой и считают, что этого достаточно. Для баз в формате MyISAM (по умолчанию) этого в общем то мало, база может оказаться нецелостной, но в большинстве случаев, проносит. Зато для баз InnoDB этого совершенно недостаточно, так как в каталоге с базой хранятся теперь только схемы, но не сами данные. Разумеется, схема - это хорошо, но истинную ценность несут данные. А потому стоит выдолбить зубилом на рогах: резервирование баз производится только утилитой mySQLdump!
Страница 574 - "после ознакомления с конструкторскими различиями" - уж хотя бы написали "конструктивными", а то совсем уши вянут.
Страница 578 - "нужно ли использовать sqlite_escape_string для кодирования полученных данных" - наверное, всё-таки декодирования, хотя я и не пользовался этой командой, название параметра подсказывает.
Во многих описаниях функций, параметры по умолчанию описаны в описании (простите за тавтологию), тогда когда для этого есть существенно более понятный синтаксис function myfunc($param='значение по умолчанию')
Глава 26 - хотелось бы отметить, что этот пакет функций как раз обычно и бывает отключён, в отличии от мускула, который вообще на всех хостингах есть и найти что-то без мускула, наверное можно, но сложно. Так что ценности в этой главе нет. Можно объяснить старостью материала.
Страница 610 - автор так любит формат wbmp, что описал его дважды!

SmiSoft, вы хоть на года издания книг смотрите перед тем как комментировать книги? Как вы думаете, как звучат ваши замечания в таком контексте? И я не только об этой книге.

fpinger:
Книга есть? Есть. Значит, кто-то может её прочитать. И начать писать неправильные программы. Именно потому такие неплохие языки, как Delphi, PHP незаслуженно хаются. Благодаря вот таким вот книгам, которые растят быдлопрограммистов, которые уверены, что раз они делают всё, как в книжечке - то это круто.

SmiSoft. не беспокойтесь о том, что не имеет значения.

Фрингер, из последних пяти комментариев полезны только первые два - от SmiSofta
А Ваш гундёжь вообще ни в тему и ничего не несёт.
Вы хоть какую-то пользу эти двумя комментарииями принесли? Другим. Людям. Кто эту книжку читает.
Да, вы даете полезные ссылки, в том числе на файлы в других темах по IT, но здесь, в этой теме..., на чужой труд..., вообще ноль полезности... в этих комментариях к этой теме.
Хоть бы что-то подобное к этой книге сделалиб.
, для тех кто из 2016-го открывает книгу из 2006,
и получает такие развернутые комментарии, пометки, и исправления/уточнения от СмиСофта.
В отличие от Вас, СмиСофт огромную работу проделал, и поделился с другими своими пометками.
К тому же СМиСофт послужил хорошим бесплатным корректором, что неоценимо.
И НЕМЕРЯННОЕ Ему СПАСИБО!
Вы хоть что-то подобное бы хоть сделали.
Проштудировав книгу, Найдя неточности, собрав их воедино, скомпиллировав и преподнеся другим, на всеобщее обозрение, с своими пометками.
Реально, у Вас бесполезный высер, не в тему, ни к селу ни к городу.
К тому же на чужую работу, труд интеллектуальный, и к тому же безвозмездный.
Тогда бы хоть понял, еслиб было по существу корректирующих пометок, если они не верны. А если верны - то опять было бы не в тему.
Вообще ниочем, Ваш коммент в этих комментариях в этой теме. Фыркать на другого за помощь другим, к тому же бесплатную, при этом сам не неся никакой помощи и пользы в этой теме другим.
СмиСофт, Огромное Спасибо и НЕМЕРЯННО благодарностей за такие пометки по всей книге, по сути бесплатный корректировщик для Нас), И Запотраченное время на работу корректировщикам во благо другим!)

Вообще-то fpinger прав, глупо требовать от книги из 2006 года технологий и методов 2016-го. Кроме того ряд комментариев SmiSoft очень даже спорен. Чтобы не быть голословным SmiSoft походу не знает ЯП, в которых можно реально вернуть несколько значений из функции, поэтому не понимает, в чем разница между этим и возвращением массива. Ага, в книге 2006 года надо было рассмотреть синтаксис от 2012 года. Явное непонимание того, что делает srand. Если можно обойтись строковыми, то лучше так и сделать. Регулярки значительно медленнее и могут сильно удивить на некоторых данных. Да и разбирать их для многих тяжело, что бьет по читаемости кода. Тут просто песня. Хайп на noSQL пошел значительно позже 2006 года, а к 2015-му во многом завершился, адекватные люди вернулись к реляционным на большинстве задач, а самые адекватные и не уходили с них. Требование надежности может быть основным. Шардинг есть и в реляционных БД. Структура данных может быть такой, что NoSQL будет в разы медленнее на всех операциях. NoSQL быстрее на маркетоидных графиках за счет работы исключительно в памяти, что умеют и реляционные БД, но у них это не дефолтный режим. NoSQL переносит работу по join и where на скрипт, что означает кучу лишнего кода, падение производительности, рост трафика. Проблем с удалением в NoSQL нет, аккаунты в социалках не удаляются по административным, а не техническим причинам. В целом NoSQL подходит только для специфического круга задач, например для социалок. Угу, только SmiSoft знает какая терминология правильная. То, что rows и cols повсеместно используются во всяких обертках для работы с БД, его не колышет. Говори за себя, ниасилятор. Ну и опять не стоит забывать каким был phpmyadmin в 2006 году. Это скорее правило, чем исключение, если мы берем первичный хостинг, а не его перепродажу. Очень умно замедлить работу БД без надобности только ради сохранения не нужного в задаче порядка записей. Разумеется наш эксперт ни в зуб ногой в администрировании, но советы дает космического масштаба и глупости. InnoDB умеет хранить данные потаблично, да-да, в каталоге с БД. Удачи ему с mysqldump на базе хотя бы в сотню гигов и таблицами на несколько миллионов записей. Сразу видно эксперта по реально большим объемам данных

Нет это противоречит самой сути функции. Вернуть можно ровно одно значение, либо некую сложную сущность, которая содержит несколько значений (массив, объект, итератор). Но фактически, функция всегда возвращает то, что содержится в регистре eax (или его аналога в виртуальной машине). Как оно трактуется - на совести компилятора. Кстати, примеры бы привели. Вероятно, вы про функциональные языки, которых я действительно не знаю по причине ненужности в моей области деятельности. Если верить php.net, то . "Случайное число" - это микросекунды от старта системы. Если вы ДВАЖДЫ вызываете последовательно srand, а потом rand - то получите одинаковые числа. Потому что вероятность, что время "тикнет" за это время мала. Ну а даже если тикнет - вы будете получать числа с "плохим" распределением. Потому мой комментарий совершенно справедлив. Единственное, что можно добавить - можно не вызывать srand, если вы используете случайные числа, но вам срать на их "качество". Доработка программы, пользующейся регулярками проще. Регулярку можно вынести в настройку (да, позволить пользователю убить программу... ну дык, ССЗБ). Обычно я выношу парсинг в отдельную функцию, чтобы трогать только её. Вне зависимости от того, что там внутри - пачка строковых операций, выполнение регулярки или ещё чего-то. Чтобы править, случись изменение чего, только её. - ну тогда про NoSQL речь и не идёт. А если нужна гостевушка? Может, её вообще можно на текстовом файле рализовать. Желательно, без блокировок, чтобы два пользователя одновременно писали в одно место и получались суперперлы. Ну, самые адекватные используют адекватные решения. У меня вот есть решение с базой данных в текстовом файле. Он обновляется раз в сутки, а "весит" полгигабайта. Решение - при получении его запускается отдельная программа, которая "сортирует" его, генерирует сортированный файл, а потом ещё одна программа выполняет поиск (двоичное дерево, как вы поняли). Если эту "базу" заливать с стандартный SQL сервер, то он "ложится" на 20 минут, что неприемлемо а в plain-text вся сортировка занимает порядка трёх минут (при этом ни Web-сервер, ни SQL-сервер даже не чувствуют, программа сортировки вываливается волшебным образом на четвёртое ядро процессора и там крутится... ничего не делал для этого, ОС сама догадалась как-то), поиск - 40 мс, что устраивает. Так что реально адекватные люди используют те решения, которые лучше всего подходят и не смотрят на то, популярны они или нет, раскручивают их или нет, любят их маркетологи... ну вы поняли. - форумов, гостевых книг, блогов, сайтов-визиток с новостями, хранящимися в БД... а таких сайтов в интернете - больше половины. - безграмотность составителей обёрток меня не волнует. Открываем классические труды и смотрим, что это такое. Именно потому я и пишу, что новичкам надо прививать правильную терминологию. Плохому они сами научатся. - ну почему, я могу работать в линуксе, но работаю в винде командном mySQL, но работаю в mySQLBrowser (это виндовая программа, работает на порядок быстрее, чем PMA, потому что нативная... но работать с базой на хостинге с её помощью нельзя). Не потому что "ниасилил", а потому что мне так удобнее. Ну поверь, ну удобнее мне ткнуть кнопку мышки, чем писать команду. Даже если её можно вызвать стрелкой вверх в баше. Так что неважно, каким бы неудобным ни был phpMyAdmin, он лучше командной строки для первичного просмотра. Я же не прошу автоматизировать процесс резервного копирования путём имитации запросов к PMA через набор вызовов curl из BAT файла (если вы думаете, что я издеваюсь, то такое решение я более чем видел в 2013 году... и оно работало годами, с 2009 года, судя по датам создания файлов). - я написал "почти". Мне не встречались задачи, где порядок был бы не важен. Разве что сбор статистики по выборке, там да - порядок несущественен. Одна задача из сотен. Для новичков лучше тупо усвоить: order by НАДО. Потому что иначе порядок КАЖДЫЙ РАЗ уникален. То, что возвращается визуально одно и то же - не показатель. Отсутствие order by сравнимо с order by random(). Узнать, что есть некоторый крошечный круг задач, где правильнее его не писать - проще, чем написать до этого тонну софта, неудобного в работе. - баз таких не было никогда, фотографии и BLOB (сканы документов, например) вообще не считаю нужным хранить в БД, только в отдельной файловой системе, резервируемой независимо. Это нестрашно, если будет некоторый рассинхрон. Получается база на сотни миллионов записей в 80 Мб (самый крупный мой проект, там хранятся документы и их атрибуты для удобного поиска и ограничения доступа), пару минут работы дампера. При этом размер папки со сканами ещё в 2013 году превышал 800 Мб. Понятно, что если их заныкать по блобам, то экспортированная база стала бы весить многие гигабайты. И, кстати, Big Data - это отдельная графа.
Как итог: взамен одного комплекта спорных моментов (в книге) я предлагаю другой комплект спорных моментов, а Angramania предлагает уже третий вариант не менее спорных моментов. Можете ещё писать, я озвучу своё мнение.

Не буду еще раз цитировать, просто пройдусь последовательно
1. Противоречит твоему личному пониманию сути функции, ведь ты просто не видел другого. Смотри Go. Это не функциональный язык и возвращение множественных значений очень полезно.
2. Согласно документации для инициализации srand вызывать вообще не надо, это делается автоматически. srand нужен в первую очередь когда надо получить фиксированную последовательность псевдослучайных чисел. И есть смысл вызвать его более одного раза, если нужно вести сразу несколько таких последовательностей. Область применения - игры.
3. Если нужен минимализм, то sqlite отлично обеспечит требования гостевушки, являясь при этом полноценными ACID и SQL
4. Не надо хвалится неумением работать с SQL БД.
5. Ну а мне удобней консольный клиент. Вот как ты phpmyadmin в пайпу встроишь? Я же говорю, ниасилятор
6. Новичкам и некоторым профи стоит усвоить, что order by снижает скорость выборки и без нужды его использовать не нужно. Задач таких много, но если говорить про типичный веб, то хочу полюбопытствовать: про сортировку на стороне клиента ты не слышал, все еще живешь принципами web 1.0?
7. Я же говорю, нет у тебя опыта работы с большими объемами данных. Сотни гигов и миллионы записей это без всяких фото и других блобов в БД. А ведь есть задачи, где несколько гигабайт без фоточек всего за сутки набегает и речь идет о терабайтах данных.
Я не предлагаю третий вариант. Я говорю о том, что надо учитывать год выхода книги и не стоит столь категорично выдавать свой опыт за истину, особенно в области, где ты сам плохо разбираешься, например в администрировании.

Неправ. Просто вы не видите разницу (и, видимо, fringer) между "требовать от книги " и "сделать Поправки(пометки) в комментариях" о пунктах с расхождением с текущим годом.
Что неподготовленному человеку который обращается из текущего года к книгам года давно ушедшего но содержательным по сути, - очень даже необходимо и неоценимо.
Ну и когда ошибки/опечатки приводятся, без привязки года, и отображаются в комментариях - это тоже очень даже круто.
А то что у Вас дискуссия пошла по сути - по содержанию книги по отдельным пунктам - это очень даже полезно всем остальным, и по сути - конструктив, который поможет выявить сегодняшние актуальные моменты,
и выявить и определить оптимальные способы года текущего остальным, особенно новичкам. стО'ит, абсолютно. Поскольку Если человек неправ, и если где-то ошибается, То найдётся другой человек с Другим опытом который его поправит, а это неоценимо новичкам и вообще другим,
А поскольку без первого человека вообще эти моменты в книге не были бы рассмотрены в комментариях и упомянуты - и именно он завязал первый нужную беседу -
я снимаю перед ним шляпу. Поскольку без того что человек первый поделился опытом - такая интересная дискуссия и завязалась, А без него бы - была пустота в комментах,
так как все "понимающие" и которые способны сами сделать такие же выводы как SmiSoft , с своего полёта "профи" и "понимания" благополучно "понимают" и понимающе молчат "у себя в голове" ни с кем не делясь, оставляя страницы комментариев пустыми и бессодержательными - и что не несет никакую пользу кто обладает в этом меньшими знаниями и пониманием или вообще новичок
, а остальные комментарии появляющиеся: вроде
"скан Плохой" и "что посоветуете ещё почитать" с стандартными никому неинтересными, уже давно всем известными ответами: читайте php.net
За сим откланиваюсь, Буду Читать книгу с интересом сверяясь с Вашими с СмиСофт комментариями, и корректируя у себя в уме данные книги года давно минувшего с актуальными данными, года текущего, благодаря комментариям всех вас
И ребят, вы меньше на личное переходите, вступая в перепалку о личных качествах и профессионализме друг друга, вы вполне можете конструктивно на профессиональную тему общаться, что очень интересно, неоценимо и полезно другим
SmiSoft"у - Отдельное спасибо и Благодарность!

1235BB, достаточно одной пометки "книга не актуальна", а писать дилетантский бред - пустое занятие.
И не обижайтесь так за SmiSoft. Если бы было что по существу, то он бы ответил.

Когда встречаю такой интеллектуальный мазохизм, всегда вспоминается древний анекдот
- займемся сексом?
- только в гамаке и в противогазах.
- почему?
- а я комсомолец, не могу без трудностей.

Мне не вспоминается
И насчет мазохизма.. мм..
Скажу так, у каждого свой подход.
И свой опыт
Ваши комменты, около 200-сот, из 1057-го я намедни тоже почитал. (было интересно, там где не касается игр)
Свойственную вам манеру общения уже знаю
У Вас свой опыт, и подход, и в изучении, и в работе, и в манере общения с другими.
У меня другой подход, и он отличается от вашего.
Для другого - что кажется трудным в действиях третьего лица, и ненужным и лишним усилием, для этого третьего дается без усилий, и трудностей, которые представляются таковыми этому другому.
То что в Вашем представлении - интеллектуальный мазохизм (я думаю большинство тоже так считают, что это бесполезная трата усилий) -
для меня - удобный мне подход, который дается мне как раз без усилий, которые вам (и возможно другим) таковыми представляются, и именно мифическим "напрягом" которого в моем случае не существует, относят подобное к интеллектуальному перенапряжению и мазохизму.
То что для вас - "интеллектуальный мазохизм" - для меня - удобный мне подход, который дается легче, и не является причинением интеллектуального напряжения.
Свой подход Вам - я не навязываю.
Вежливей общаться (опять же на основе прочитанных ваших сообщений из профиля - не скрою, помимо хамовитости содержат много интересного) - не призываю.
Зачем читать книгу 2006-го в 2016-м, и в частности именно эту, именно этого автора и именно этого издания, когда есть Зандстра, PHP MVC Pro от Chris'a Pitt'a, Книга Того же Кевина Янка на русском от 2013-го которого я раздаю, любимый всеми (или многими) Люк Веллинг - у меня на то внутренние причины, почему читать именно эту книгу, и некоторые подобные старого издания 2006-х - 2009-х годов по PHP.
Озвучивать те причины - не хочу тратить время на это да это и не имеет смысла и никому не интересно.
У меня другой подход, к изучению, который я выработал, и который мне, персонально мне, легче и удобнее чем, возможно более общепринятые подходы других, просто он проще и удобнее персонально мне.
И это книга - и мой интерес к ней, в этом топике - оказалась частью моего подхода - кусочком айсберга что-ли, оказалась в фокусе моего подхода по определенным причинам, потому щас она также и в фокусе моего внимания.
У Вас другой подход, и в обучении, и в работе, и вы безусловно более опытный специалист, судя по вашим комментариям.
Просто у меня то что вам представляется интеллектуальным мазохизмом - для меня (персонально для меня) таковым не является.
Например для меня интеллектуальный мазохизм в действиях других - когда начинают изучать php с чтения мануала на php.net , При этом (входящее условие) - не обладая доселе никакими навыками и опытом программирования в других языках.
Но многие "гурии" с большим опытом, это советуют новичкам.
Я знаю насколько популярен такой подход-совет, но честно скажу - большего бредового подхода-совета я не наблюдаю, включая чтение популярных форумов, для меня это - пик и верх интеллектуального мазохизма и бесполезности и безрезультативности на выходе.
Но опять же - только для меня, - с некоторыми это как раз и работает (мануал+форумы - и бежать с каждым непонятным вопросом в топик на форум для обсуждения с гурами).
Ну что ж, у других - другой подход, и он им, в результате их внутреннего специфического строения ума и предрасположенности именно к такому способу обучения/постижения - более подходит, - и им является более легким, удобным и быстрым, чем мне. Свой я им не навязываю, если в результате внутренней специфики мышления он им подходит больше чем мне, и более результативен, чем еслиб они использовали иной подход.
Ну чтож у них другой подход, у меня - свой, у третьего - третий.
Каждому своё.
Приведу вам цитату ещё одного авторитетного пользователя по этому поводу:

angramania: Наконец то пошёл конструктив. Рад. возможно, видел (код на Go немного приходилось читать), но это противоречит не только моему представлению, но и данным на Википедии. Нет, я не говорю, что Вики - это истина в последней инстанции, но всё-таки, согласно ей, функция возвращает ровно одно, можно пустое значение. ну и замечательно. То есть 0 раз. И... не понял, как можно сгенерировать НЕСКОЛЬКО разных последовательностей одновременно? Инициализировал первым семенем (seed) - идёт одна последовательность. Инициализировал другим - другая. Но не две одновременно. Если мне надо две последовательности - то я создаю отдельный класс, в котором всё та же (A*x+B) mod 2^Z, но отдельно инициализированное первое значение. Ну, либо другой генератор, потыренный по интернету. Криптографией я не занимаюсь, а для игрушек покатит. речь немного не про то. Для реляционной БД будет естественна таблица comments (int user_id, int created, text content). А для NoSQL - comments (var_char user_name, var_char user_homepage, int created, text content). И моя практика показывает, что современному программисту "удобнее" видеть прямо в таблице не значения вида 1,2355654545,"Первый комментарий"), а более осмысленное: ("Вася Пупкин", "http://poupkine.net/user/Poupkine", 4545474545, "Первый комментарий"). Выводить проще (inner join нету), можно без вопросов ввести ввод данных через OAuth (не требуется регистрация в базе, достаточно вытянуть только имя пользователя и его хомяка... ну, может, что ещё), можно вообще брать данные от неавторизованных пользователей. На традиционной реляционной модели это не сделать. Ну, либо отвязывать всё от всего и переводить проверку целостности в код (что лично меня вообще никогда не радовало, я всегда старался вывести всё в констрейнты, хранимки, индексы и прочее - на сервер БД, короче). да вроде как не жалуюсь. Правда, с "голым" SQL давно не работал, всё SQL-builder, ORM, NotORM (кстати, прикольная штука, если не видели - http://www.notorm.com/ посмотрите, для мелких проектиков нормуль, не тащить же доктрину). пардон, а зачем? Я вот вижу задачу командной строки только в том, чтобы восстановить работоспособность сервера, если гуй не отвечает. Всё остальное удобнее делать в гуе. Ну, обленился, может быть, не без этого. слышал. Но для этого надо данные туда подтянуть. Всё. А пагинация? Ты будешь смеяться, но я даже AJAX в своих проектах почти не использую. Ну не вижу я в нём профита. Нет, ну там, где надо (например, есть таблица на 1000+ записей, которая регулярно обновляется несколькими клиентами, но в большинстве случаев клиенты записи друг друга не видят... а потому по таймеру (я знаю про вебсокеты) я спрашиваю сервер, нет ли обновлений и если есть, то встраиваю данные прямо в таблицу так, что клиент часто даже не замечает, что творится) - там - почему бы и нет. А делать форму авторизации на аяксе, или отправлять комментарии аяксом... простите, смысла не вижу. А, и ещё - можете вообще меня в ад отправить, я до сих пор не брезгую табличной вёрсткой и даже фреймами, если я сочту их использование обоснованным в данном конкретном случае. Я вообще то и не выдавал свой опыт за истину в последней инстанции. Просто есть такая штука... если есть теория и некоторый набор фактов ей соответствует, то это НЕ значит, что эта теория истинна. А если есть теория и есть один факт, которые ей противоречит, то это ЗНАЧИТ, что теория не верна. Как в задаче про щит и меч... несокрушимым щитом надо прикрыться со всех сторон. Всепроникающим мечом достаточно поразить одну точку. Здесь тоже - нужно хотя бы знать, где ошибка. Для того комментарии и существуют. Год выхода книги... неважен. Вы можете поспорить, но я неоднократно сталкивался с проблемой, что в более новых выпусках только добавляется новый материал, но не исправляется старый. Первая моя книга по PHP... Ларри Ульман... по PHP 3.0 ещё. Я теперь знаю, какие там ошибки есть. В более новых изданиях они все скурпулёзно перепечатаны. Просто если я вижу противоречие СВОЕМУ опыту - это гарантированно значит, что данный факт неверен. Ну а если я говорю о каком-то решении, которое работало у меня, то это не факт, что оно правильное. Смотрите выше, про теорию и щит с мечом. ну почему сразу так... Кое-какие полезные для себя вещи я из этой книги вынес... читая уже в 2015 году. Немного, конечно, но, возможно, если бы я раньше прочитал эту книгу, то я бы смог воспользоваться этой информацией раньше, с пользой для себя. Я по существу и отвечаю. Тут у меня такое правило... необоснованная критика меня не задевает, потому что она необоснованная. А обоснованная не может задевать, потому что она обоснованная. Например: я не знаю функциональных языков программирования и не встречался с функциями, возвращающими пачку значений. Ну и что на это обижаться, если это факт? Про терминологию... тут вопрос вообще хитрый... взять хотя бы авторов SQL и их drop column, add column, что противоречит общепринятой терминологии. И что, после этого всем называть поля столбцами? Я подозреваю, что именно тут собака и порылась, почему во многих обёртках именно columns, а не fields. Кстати, в более старинных языках (типа Delphi) всё-таки повсеместно используется именно Field, а не Columns. Пошли на поводу у олбанцефф? Езыг нышто, храматнась - фуфло, каг хатым, таг ы гаварым! Ну и про то, что я не помню (реально, не помню) в каком году появился phpMyAdmin (его и вообще могло не быть, я же не против) и в каком году появился синтаксис [] - ну не знаю я просто... ну для полноты картины написал. Просто когда я столкнулся в этим вариантом (а также NowDoc синтаксисом), я впитать не мог - что тут написано. Узнал. Понял. Никогда не использую и использовать не буду. Администрирование. Ну, у меня всё, что было - это одинокий сервер. Знаю про галочки шардинга, резервного копирования и некоторые другие вещи. Просто знаю, но никогда не пользовался. Надо будет - разберусь.
Получается, что редко на какую критику можно обижаться. Ну разве что критикуют собственное ИМХО. Но оно на то и ИМХО...
А анекдот про комсомольца... а знаете, что нет максимально полной литературы по любой тематике? Приходится читать несколько книг, знакомиться с разными точками зрения, смотреть примеры... И старая литература, со старыми взглядами, тут может и не помешать, а больше поспособствовать. Я вот читаю сперва новую литературу, а потом начинаю просматривать старую (да, в большинстве случаев - просто просматривать, как эту книгу, пропуская большие куски, надеясь, что всё, что там есть, я уже знаю). Вот, отличное замечание. Представьте себя новичком и попробуйте по той документации что-то изучить (любой специалист должен уметь мысленно "забывать" всё, что он знает и становиться уборщицей, которая в жизни никогда никаких "синих экранов и белых ящиков" не видала - для меня это абсолютно необходимое условие существования специалиста)? Не можете (представить или изучить)? Вот то-то. А заглядывать туда, чтобы посмотреть, какой порядок аргументов у implode и какие тонкости работы у array_merge - ну так это сам Расмус Лендорф велел.

SmiSoft и 1235BB, вот ещё немного "не обоснованной" критики для вас. Вы не практики, а иначе бы спокойно относились к обучению по мануалу и лучшим последним книгам, отражающим живое развитие языка разработки. Но это не обвинение. У каждого из нас свои умопромрачения. Кто-то, как переполненная чаша ковыряет старые книги и делает пустые выводы, боясь сделать шаг вперёд, отпустить бесполезное занятие и заняться чем-нибудь нужным сейчас. А кто-то не справляется с раздражением, видя глупости и невозможность налить в чаши свежего чая. Хотя от этого раздражения толку нет. Других насильно счастливым не сделаешь. Не запретишь беспокоится по пустякам и делать бесполезные поступки.

Фрингер, так я и не претендую.
Я и указал выше что с интересом читаю комментарии выше более сведущих - angramania и SmiSofta, я только учусь так что здесь никакой критики меня нет)
Скорее констатация факта чего я о себе и не скрываю. )
Я учусь, кому то не понравился мой подход - что он мазохистический для него бы оказался , - я указал что у всех он разный. Свой не навязываю. И за чужими не гонюсь.
А коммент выше SmiSofta, о книге был мне очень полезен
Так что я и не претендую на "практиков" "гуриев" от php и прочих "профи".)
Так что здесь никакой критики меня нет, я и сам это не скрываю, потому и нахожусь в ветке о книге, пусть и старой, которая встала передо мной в ходе определенных причин ввиду моего подхода к обучению, который меня именно к ней и привел, а не на форумах о том как получить Zend сертификат)
А комменты SmiSofta помогли мне заранее отметить с какими устаревшими данными я столкнусь

Про какую вообще функцию идет речь? Есть математическая концепция функции, а есть ее перенос на подпрограммы в программировании. В математике это определенный способ отображения одного множества на другое. В самом простом и распространенном случае у функции не только одно значение, но и один аргумент. Однако почему-то наличие множественных аргументов у подпрограмм тебя не смущает, а наличие множественных значений смущает. Опять таки в математике спокойно существуют функции как с несколькими аргументами, так и с несколькими значениями. Точно также существуют ЯП, где возврат подпрограммой нескольких значений нормален и способствует определенному стилю программирования. Согласен, одновременно нельзя, только со своим собственным ГСЧ. Да почему не сделать, тебя кто-то под дулом пистолета заставляет соблюдать нормализацию? Если академичность нормализации в одном месте вступает в противоречие с требованиями объективной реальности, то нафиг нормализацию в _этом_ месте. Я не про незнание SQL языка, а про то, что при работе с реляционными СУБД всегда есть куча нюансов, знание которых легко может сократить время операций на порядки. Если оптимизированный скомпилированный код СУБД выполняет задачу дольше, чем твой скриптовый код, значит ты что-то делаешь не так при работе с СУБД.
Другое дело, что иногда написать свое решение проще и быстрее, чем пытаться разобраться с такими нюансами. Если я еще раз скажу про "ниасилил", то это уже из подколки станет оскорблением, так что лучше разъясню. По опыту своему и коллег могу сделать однозначный вывод: о удобстве гуя на _большинстве_ задач говорят те, кто не приложил должных усилий, чтобы освоить командную строку. Освоить - это не быть способным сделать что-то в ней раз в пару месяцев, а несколько месяцев решать все задачи только в ней. В противном случае не получится побороть старые привычки и выработать новые. А вот после такой "ломки" уже можно возвращаться к использованию гуя в тех случаях, где он реально(а не в силу привычки и незнания альтернативы) удобней. Так что дело не в лени или неспособности, а в том, что в силу обстоятельств тебе не приходилось проходить через "ломку" и твое "удобней" означает лишь "я не владею другим способом". Узнаю собрата практика Ключевое слово было "категорично", а не сам факт выдачи личного опыта за истину, что является вполне нормальным действием. Вообще-то это легко может означать, что теория неполна, а не неверна. Классический пример это ньютоновская механика. А вообще это вопросы философии и их дальнейшее обсуждение будет офтопиком. Или ты что-то делал неверно, либо чего-то не знал на момент действий. Например твои утверждения про мускул. Речь не про ошибки, которые переносятся в новые издания, а про то, что ты упрекал автора в незнании материала, которые на момент выхода просто не существовал. Посмотри свои формулировки, это именно упреки, а не просто пометки о том, что с тех пор появились новые способы сделать что-то.

Вот именно последнее и заставляет работать со своими решениями. Ну вот, например, в используемом мною фреймворке ну не умеет ОRM сделать сразу select o.created,u.name,o.description from actions a inner join operations o on o.id=a.operation_type inner join u.id=o.user_id. В итоге получается ТРИ запроса вместо логичного одного (и, вероятнее всего, быстрее выполняющегося). Тем не менее, после некоторых размышлений, я решил, что проще (и понятнее для последователей) забить на эту эффективность... и вместо использования двух методов (SQL и ORM) использовать только ORM, а то вдруг не поймут. Хотя он и менее эффективен. Так что добавьте сюда ещё и унификацию... или как это ещё назвать... Ну, написать задачу для крона (ну или планировщика задач)... можно, кстати, и PHP из командной строки, если возможностей bash (или batch, или PowerShell, если винда) не хватает - так это завсегда пожалуйста. Здесь речь именно о лени - я могу выполнить и так задачу и так, но писать команды ленивее, проще стоять на базе и жать одну кнопку всё-таки гуй. Но только там, где он на самом деле проще. А так - я только за то, чтобы человек знал МНОГО вариантов решения (MySQLBrowser - GUI нативное приложение, phpMyAdmin - набор PHP скриптов, командную строку), потому что это позволит решать задачи более оптимальным путём. А так короче получается. Вот знаете про такой анекдот, что каждое упоминание Исламского Государства должно сопровождаться примечанием: (террористическая группировка, запрещённая в Российской федерации). Как по мне - так маразм. Здесь как бы то же самое... Вы можете также придраться к тому, что я упрекаю автора в отсутствии описаний now doc, here doc, autoloader - я честно говорю, что не знаю, когда они появились. Даже не всегда вспомню, когда я о них узнал... вот сейчас знаю - и всё. А про некоторые вещи - не знаю, хотя могу и догадываться. Тут вопрос в том, что читает комментарий (и книгу, если захочет) читатель именно сейчас. А новой редакции ЭТОЙ книги нет, она до сих пор продаётся в бумаге: http://www.ozon.ru/context/detail/id/2571317/ - так что ИМХО, но замечания (кстати, кое-где это юмор, если вы не поняли... например, про спарту) вполне уместны.