Введение

В своей предыдущей статье я дал краткий обзор основных моделей хранения иерархических структур в реляционных БД. Как и положено тому быть, у многих читателей стал вопрос ребром о производительности представленных алгоритмов.

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

Введение

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

В первую очередь, это связано с тем, что реляционные базы не приспособлены к хранению иерархических структур (как, например, XML-файлы), структура реляционных таблиц представляет из себя простые списки. Иерархические же данные имеют связь «родитель-наследники», которая не реализована в реляционной структуре.

Тем не менее, задача «хранить деревья в базе данных» рано или поздно возникает перед любым разработчиком.

Ниже мы подробно рассмотрим, какие существуют подходы в организации хранения деревьев в реляционных БД, а также рассмотрим инструментарий, который нам предоставляет ORM Doctrine для работы с такими структурами.

Кросс-пост из нашего блога, посвященному компьютерной безопасности

Ранее мы писали о уязвимостях каптч на сайтах компании Киевстар и Билайн. Теперь мы хотим, вашему вниманию предоставить наше исследование в области взломов и защиты каптч.

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

UPD: После многочисленных коментариев я сильно переработал статью, внес в неё больше конкретики и примеров, а так же убрал спорные моменты (например, касательно memcached). Спасибо всем, за конструктивную критику.

В данной статье я попытаюсь описать практические стороны кэширования, ориентированные, прежде всего, на сайты и системы управления контентом. Сразу предупреждаю, это мое личное мнение, которое не претендует на истину в последней инстанции. Большинство терминологии — моё, вы можете использовать его, если считаете нужным на своё усмотрение. Конструктивная критика приветствуется.

Ни разу не слышал, чтобы наши (читай: совковые) вендоры коробочных CMS заказывали usability тестирование своих продуктов. Напрашивается два основных вывода:

1. Usability этих систем и так на высоте! В каждой компании есть свои usability специалисты, которые принимают участие в разработке на всех стадиях развития продукта – организуют тестирования, дают рекомендации, экспертную оценку и т.д. В таком случае это UDD – User-Driven Development.
2. Usability этих систем по-взрослому сосет. Программеры делают функционал. Дизайнеры делают дизайн. Маркетинг делает продажи. Программер думает об эклипсе. Дизайнер думает о фотошопе. Маркетолог думает о пауерпоинте. Ну а конечный пользователь периодически задумывается обо всех трех сразу – об их интеллекте, сексуальной ориентации и месте произрастания их передних конечностей. Это методология AUDD – Anti-User-Driven Development или Angry User Driven Development.

Если вам известны компании, которые работают по первой схеме, то дайте знать. На ребят, делающих все по второй схеме, я насмотрелся вдоволь, поэтому считаю полезной для всеобщего ознакомления публикацию «11 usability principles for CMS products» за авторством James Robertson. Далее позволю себе привести вольный пересказ списка из одиннадцати принципов CMS usability, которые выделяет Джеймс, с моими комментариями.