Кстати, про веб-программизм

Одной из самых неудачных черт 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, когда вся его роль может быть сведена к форматированию отданных СУБД данных?

Кстати, про веб-программизм: 6 комментариев

  1. Ну вообще есть такая вещь как нереляционные базы данных. В том же Lotus Domino одна запись это один документ целиком. Как раз примерно одним селектом и получается.

  2. 1. к сожалению, более удобного способа хранить какой-нибудь ассоциативный массив (”хеш”) между различными выполнениями скрипта в PHP нет.

    http://php.net/manual/en/book.apc.php

    2. подобное использование БД – “нецелевое”, оно провоцирует на то, чтобы рассматривать базу данных, как какую-то “помойку” без определенной структуры

    этому спору 20 лет минимум. Со времен когда Novel притащил на писюки первый SQL сервер. Кучу купий сломали на предмет где хранимые процедуры, где транзакции, что должен делать аппликейшен сервер, трехзвенная архитектура и прочий мусор, которые вы, молодежь счастливо пропустили.

    Практический вывод 1. Единственная СУБД, которая можете теоретически выполнять запросы нужные в реальной жизни — DB2. Все остальное нуждается в костылях. Да и дибита тоже.
    Практический вывод 2. Так как логика сложная, то запихивать ее SQL сервер — тупиковая ветвь по изобретанию альтернативных языков програмирования. Ну там еще была агония с обратным встраиванием питонов и джав в сервера БД. В результате MySQL всех заборол за счет того, что не содержит, всякого, извиняюсь, говна.
    Следствие новомодное. По мере развития веба встал вопрос масштабирования, кластеризации и облачности и тут реляционные СУБД, которые требуют атомарного изменения многих связанных таблиц оказались гвоздем в ботинке. Кинут клич — долой SQL, храним только хеши — ID/значение, где значение может иметь сколь угодно сложную структуру, но пара ID/значение гарантированно хранится на одном узле БД. Читать гугль на предмет NoSQL. Старые пердуны моугт подрочить на Novell Btrieve — «мы то всегда знали»

    :но разве нельзя так делать сайты?

    Если бы не высшее образование им. Канделаки-Фурсенко, то в некотором роде нужно. Называется REST-протокол. На клиента, в браузер, загружается одна страница, фактически JS-код, которая дергает HTTP-сервер, короткими запросами GET (найти ресурс), DELETE, PUT (update) и POST (insert) и полученные результаты отображает JS’ом. В зависимости от степени безумия возвращенный ресурс может быть HTML (например) кодом, представляющий целый визуальный элемент. Имеем старый добрый клиент сервер. Недалек тот час, когда сетевый OS сольют десктоп и сервер в один континиум и те повелители Дибейза и Клиппера, которые не откинут еще копыта, окажутся вновь востребованными специалистами.

    1. 1. Я говорю за тот «стандартный» PHP, который люди изучали по статьям в журнале «Ксакеп» или книжкам «PHP для чайника».

      2. По воводу «практического вывода 2». Я не призываю пихать в БД _всю_ логику, тем более, если она сложная. Многие вещи сложной логики требуют лишь при вставке новых данных, а вывод — совершенно «стандартный». В принципе, это можно втиснуть в предложенную модель с «визуализацией» — например, весь ввод обрабатывается еще каким-нибудь «валидатором», тоже немного отличающимся для разных задач.

      Про REST интересно, спасибо.

  3. А то еще можно помудрствовать на тему отмирание концепции БД как таковой. На ее место приходит Persistance. Т.е. объекты программы просто «как-то» переживают стоп-старт программы.

    В Google App Engine в качества механима сохранения состояния используется как раз не-реляционное хранилище. Java-объекту говорится ‘.store’ и все, дело сделано — в любой момент можно его найти по id, и будет сразу восстановлен как объек языка Java без всяки промежуточных манипуляций с селектами. Забавно при этом, что SQL остался огрызо в виде ‘FROM … WHERE …’ — перечислять поля стало бессмысленно, а вот условия того, какие именно объекты выбрать еще не потеряло своей актуальности.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *