С начала активных боевых действий против попингуев прошло уже достаточно много времени. Я, честно говоря, ожидал гораздо большей активности со стороны пользователей да и самого автора скрипта блога. Однако ж тишина... Может это только мне попингуи доставляют неудобства?  Ладно, речь не о том. Я считаю попингуйство злом и намерен продолжать с ним бороться.

Предыдущая версия "Привратника" работала довольно сносно, но, к сожалению, не долго - создатели "пингуляторов" быстро поняли свои ошибки и приняли меры. Теперь простой анализ частоты хитов уже не помогает. Что ж, значит пришло время сделать выводы и пересмотреть стратегию.

Чуть более недели назад старый "Привратник" на этом сайте был списан на пенсию и его место занял новый, переписанный заново и использующий совершенно новый подход. Теперь он не смотрит ни на IP-адрес посетителя, ни на его юзер-агент, ни на все остальные "атрибуты" - это просто не нужно.

Вместо этого он выкачивает страницу, с которой якобы пришел посетитель и пытается найти в ее коде ссылку на запрашиваемую страницу. Ежели нашел - значит все в порядке и можно пропускать хит дальше в блог. Ну а если ссылку обнаружить не удалось, то попингуй получает болт калибра 404, а блог даже не подозревает, что кто-то пытался на него зайти.

Неделю скрипт работал в тестовом режиме - ничего реально не делал, лишь подробно описывал в логах свои мечты и желания - кого он признал "живым", а кого с удовольствием послал бы на три веселых цифры. Анализ этого лога позволил выявить некоторые недочеты и ошибки, внести исправления и, наконец, сегодня дать таки ему право безжалостно херить всех неугодных.

Итак, начат второй этап тестирования. Для чистоты эксперимента статистика блога (уже в который раз) была обнулена и снова выставлены на общий обзор "друзья сайта". Любуйтесь, комментируйте. Самые активные смогут первыми получить сей скрипт в свое распоряжение. 

Дополнение от 5 июня.

Сегодня обнаружил досадную ошибку в скрипте - он добросовестно определял попингуйские сайты, но по-привычке никаких мер по присечению их деятельности не предпринимал. 

Сейчас положение исправлено, но пришлось снова очистить статистику... 

Как хранить данные в БД? Этот вопрос рано или поздно встает перед любым проектировщиком сайта.

По теме проектирования баз данных написано множество книг и статей, но все они содержат больше технической информации (описания систем индексации, поиска и связывания таблиц) и предлагают дробить всю информацию на множество таблиц, не забыв склеить все это в тугой узел с помощью связей (relations) и зависимостей.

Но всегда ли это оптимально? Так ли сильно отличаются наборы хранимой информации для разных видов контента? Давайте рассмотрим, какую информацию хранят в БД "типовые" виды контента сайтов.

Статичная страница.

Это страница, содержащая некоторую полезную для посетителя информацию, которая очень редко (или вообще никогда) не изменяется. Список полей-атрибутов этого вида контента:

• Уникальный идентификатор (id) - куда ж без него?
• Идентификатор родительского элемента сайта (parent_id - мы же строим иерархическую систему)
• Заголовок (title)
• Описание (description)
• Краткое содержание (summary - используется в качестве анонса)
• Собственно текст старницы (content)
• Ключевые слова (keywords)
• Идентификатор автора (user_id)
• Дата создания (created)
• Дата последнего изменения (modified)
• Флаг опубликованности (published)
• Идентификатор логического раздела (category)

Вроде ничего не забыл....

Статья в блоге.

Представляет собой обычную статичную страницу, но еще предоставляет возможность пользователям оставлять комментарии. Соответственно набор полей тот же, что и у статической страницы.

Комментарий к статье блога.

В плане хранения информации, отличия от статичной страницы минимальны. Список полей:

• Уникальный идентификатор (id)
• Идентификатор статьи с в блоге, к которой относится данный комментарий (parent_id)
• Заголовок (title)
• Собственно текст (content)
• Идентификатор автора (user_id)
• Дата создания (created)
• Флаг промодерированности (published)

Как видим, поля всё теже, что и для статичной страницы, отличие лишь в количестве.

Пост в форуме.

Полностью совпадает со статической страницей.

Ответ к посту в форуме.

Полностью совпадает с комментарием к статье блога.

Запись в новостной ленте.

Полностью совпадает со статической страницей. Лишь будет иметь одно дополнительное поле:

• Дата, начиная с которой новость уже не актуальна (expiried)

Товар в магазине.

Используются все теже поля, что и для записи в новостях, но с небольшими дополнениями:

• цена единицы товара (price)
• количество товара на складе (number)
• картинка товара, лишь для удобства - никто не запрещает ее вставить в само описание товара (image)

Итог.

Проанализировав описанное выше, можно легко сделать вывод, что при проектировании CMF логично создать всего одну (большую) универсальную таблицу в базе данных для хранения практически любого вида контента. При этом для разработчиков модулей можно упростить многие рутинные операции, такие как, программирование ввода одних и тех же данных в разных модулях (created, modified, title, decsription, keywords и т.д.). Разработчику модуля нужно лишь сообщить системе, какие именно поля будет использовать его модуль и система сама сможет создать все необходимые формы для ввода/редактирования данных, с необходимой валидацией.

Так же этот вариант хранения данных позволяет сделать "прозрачную индексацию" - поскольку система имеет доступ ко всему контенту (и что важно - ей не нужно для получения контента обращаться к модулям, его создавшим!), то она запросто может сканировать его и строить необходимые для реализации поиска по сайту таблицы.

Сюда же стоит отнести и возможность отслеживания обновления контента без участия системы оповещения (событий), а так же и решение многих проблем, связанных с кэшированием.

Да и работать оно должно веселее, т.к. БД постоянно будет использовать одну таблицу, а значит часть ее всегда будет торчать в памяти (кэше), соответственно запросы должны выполняться гораздо быстрее...

Только что посмотрел первый полу-финал конкурса "Евровидение - 2009". Обычно такие вещи не смотрю, в виду полного отсутствия интереса к мероприятиям подобного типа, но сегодня пришлось - мать просила записать конкурс.

Мне, как технарю по натуре и как экс-оператору/монтажеру-свадебщику, шибко понравилась операторско-режиссерская работа. Летающая между исполнителями камера произведа весьма позитивное впечатление. Так же, как и нагромождение огромных слегка летающих экранов и то, что по большей части на этих экранах отображалось.

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

К сожалению на телевизоре узреть всю прелесть и масштабность оформления не удается. Я только к середине программы заметил, что огромное кольцо из полукруглых экранов (прямо над головами исполнителей) время от времени меняет свою "конфигурацию". 

Что же касается самих исполнителей, тут я патриотизмом не отличусь - мне больше всех понравилась исландия (на фото) - симпатичная блондиночка с приятным голосом и миленькой песенкой. Еще, на мой взгляд, очень хорошо выступил коллектив из Армении. Остальные впечатления не произвели - все какое-то посредственное и не интересное.

А вы что думаете?