Метка: сайтоводство

Когда-то давно, еще, наверное, в IE5, при вводе в адресную строку чего-то, заведомо не являющегося URL, браузер искал это с помощью поисковика MSN или чего-то прописанного вместо него (хоть замена MSN на другой поисковик нигде не описывалась). Итого в панели браузера имелось лишь одно поле ввода, предназначенное как для поиска, так и для ввода URL. В современных браузерах существуют отдельные поле ввода URL и поле для «быстрого поиска», причем понять, что для чего предназначено, «юзеру» затруднительно (не говоря о том, что многие не отличают поле ввода поискового запроса на Яндексе от поля ввода URL в браузере). По-моему, получилось просто усложнение интерфейса.

И еще. Читал вчера у Joel’а по поводу картинок в FrontPage. Вспомнилась еще одна неприятная штука с картинками в HTML. В свое время считалось, что загрузка картинок в браузере может быть отключена, и тег img был снабжен атрибутом alt, в котором должен был прописываться некий текст, описывающий изображение. В «элементарных руководствах» по HTML всех призывали писать в нем описание картинки, что-нибудь типа «Белое облако, летящее с востока на запад». Надо ли говорить, что никто сегодня этим атрибутом толком не пользуется? К сожалению, человечество так и не придумало, как нормально снабдить графический файл альтернативным «текстовым описанием». Возможно, имело бы смысл отправлять эти данные в HTTP-заголовке, тогда вместо загрузки большого файла целиком можно было бы обойтись только запросом HEAD. Впрочем, все получилось так, как оно есть, с полной невозможностью найти картинку по ее описанию в «поиске по картинкам».

Одной из самых неудачных черт PHP (да и вообще современного сайтостроительства) лично я считаю то, что очень неудобно хранить настройки где-либо, кроме базы данных. Конечно, почти всегда существует текстовый файлик с назанием типа config.php или config.inc, но в нем прописываются только параметры, необходимые для доступа к БД. В вордпрессе, например, такие параметры, как часовой пояс, название темы оформления и тому подобные хранятся в отдельной таблице БД, имеющей очень простую структуру — имя+значение. Если надо «узнать» один из этих параметров — пишите запрос :)

Я не знаю, как это можно «согласовать» с реляционной моделью, но, к сожалению, более удобного способа хранить какой-нибудь ассоциативный массив («хеш») между различными выполнениями скрипта в PHP нет. Но дело не только в этом. Как мне кажется, подобное использование БД — «нецелевое», оно провоцирует на то, чтобы рассматривать базу данных, как какую-то «помойку» без определенной структуры, а не на очень удобное средство для хранения и (что более важно) выборки данных.

Хорошо спроектированная база данных вообще не нуждается в PHP-обертке, роль скриптов должна сводиться к «красивому» форматированию данных, полученных SELECT-ом. Может, конечно, я заново изобретаю велосипед (во всяком случае, идеи очень похожи на принцип Model-View-Controller), или призываю к «экстремизму», но вот мне кажется, что большинство движков веб-сайтов можно заменить на PHP MyAdmin :) Наверное, вряд ли это новость, но недавно я видел одну систему, построенную по довольно оригинальному принципу: есть база данных с кучей таблиц. Каждая таблица соответствует страничке сайта, которые строятся одним и тем же скриптом. Данные в таблицы можно добавлять через автоматически генерируемые веб-формы.

В принципе, это еще один шаг в сторону «веб-программирования мышкой«. Уже есть автоматизированные средства создания структуры БД (например, на основе Entity-Relationship диаграмм). При желании можно определить «визуализаторы» для различных типов SQL-запросов (например, запись в блоге или лента записей выводятся с указанием заголовка, автора, даты и т. п., комментарии — «лесенкой» или линейно), «вставить» их мышкой на страничку и получить готовую CMS для блога. Например, страничка, содержащая запись и комментарии к ней, полностью генерируется за два запроса:

SELECT author, title, text FROM entries WHERE entryid=$id;
SELECT author, text FROM comments WHERE entryid=$id;
Достаточно правильно отформатировать то, что вернула нам СУБД — и все готово!

Конечно, реальные запросы будут сложнее, например, явно стоит сделать таблицу authors (с полями типа name, surname, avatar), которую надо «соединять» с entries и comments, но все содержимое страницы определяется только SQL-запросами.

Есть, конечно, шутки об уникумах, которые сооружали сайты только на SQL-запросах (да-да, добавляя туда HTML-форматирование), и тем самым обеспечивали себе свое рабочее место до глубокой старости (потому что ни один пэхэпист ни в жисть не поймет, что это за извращение), но разве нельзя так делать сайты? И разве всем так нужны возможности тьюринг-полного PHP, когда вся его роль может быть сведена к форматированию отданных СУБД данных?

В который раз убеждаюсь, что изложение SQL в «непрофильных» книжках по всякому там PHP приводит разве что к бесконтрольному распространению похапешных кодеров.

Недавно наблюдал замечательное — из базы данных извлекаются все записи таблицы (SELECT * FROM foo.bar;), затем сортируются пузырьком (!) в PHP-скрипте (про usort() аффтар был не в курсе), а затем выводятся те из них, которые имеют значение некоторого числового поля, равное 0 и 1. Про существование WHERE и ORDER BY мега-похапешник был не в курсе.

Собственно, осуждать похапешника и обвинять того в быдлокодерстве не стоит — я и сам был таким, делал сайты на самописном подобии CMS. Все это даже работало — с посещаемостью два недочеловека в день и не такое работать будет. Впрочем, некое «оправдание» у меня есть — я «изучал» SQL и PHP по статьям в журнале «Мурзилка» «Ксакеп». С гордостью могу заявить, что никаким SQL Injection у меня никогда не пахло! Впрочем, больше ничего хорошего сказать нельзя. Чему можно научиться вот из такого?

$sql2="select * from xforum";
$res2=mysql_query($sql2);
$a=mysql_num_rows($res2); #считаем количество тем в форуме
$b=ceil($a/30); # считаем количество страниц с результатами запроса
echo "Страницы: "; for ($i=1; $i<=$b; $i++) {if ($i!=$page) {echo "<a href=forum.php?page=$i>";} echo "$i"; if ($i!=$page) {echo "</a>";} echo " ";}
# выводим в цикле список доступных страниц с сообщениями
$sql="select * from xforum order by 'pid' desc limit $from,29"; #запрос на постраничный вывод дискуссий форума
$res=mysql_query($sql);

Собственно, самые продвинутые похапешники, которые даже знают «классические» алгоритмы, могут не заморачиваться со вторым запросом, а, как я уже говорил, отсортировать все «пузырьком». А представляете, что творится, когда в таблице xforum хранятся не короткие заголовки тем, а что-то более содержательное?

Я не говорю про всякое сложное типа «нормальных форм», но почему-то большинство похапешников совершенно не представляют себе, что такое SQL и что он может. Самое главное — это не мешает им считать себя большими специалистами по базам данных (умеют написать UPDATE и SELECT). Не так давно видел «критику» одного популярного вордпрессовского плагина — человек немного потупил в код, переписал пару SQL-запросов, убрал «сортировку пузырьком» — и добился весьма существенного роста производительности.

И эти люди запрещают нам ковыряться в носу :)

UPD Все было еще круче! Сортировка пузырьком понадобилась ровно по той причине, что чел просто не разобрался, как использовать usort(). Интересно, а лет пятнадцать назад, такие же монстры писали на C?