четверг, 22 апреля 2010 г.

Бросок к свободе И.В. Беркут.

Игорь Беркут, лидер партии «Великая Украина».
Подробности инцидента в аэропорту Франкфурта-на-Майне.

часть 1


часть 2

суббота, 17 апреля 2010 г.

Про разработку на PHP

Всё больше и больше заглядываю в доки по MySQL потому что не хочется писать кучу громоздких функций на PHP для выполнения тривиальных задач.
вот в тему, надыбал очень полезную статью на phpclub'e, для начала: "Работа с MySQL: Подробнее"
1. Запросы на выборку данных (SELECT)

* Во избежание путаницы полей (если встречаются поля с одинаковыми названиями) используйте в запросах оператор AS: "SELECT table1.id as id1, table2.id as id2". Это поможет избежать ошибок в запросе (например, если не указана таблица, а поле с таким названием есть в нескольких запрашиваемых таблицах, mysql выдаёт ошибку), а так же вы избежите недоразумений при работе с полученными данными (echo $row["id1"] писать гораздо проще, чем $row[$x]).
* Данные типа DATE, TIME, DATETIME и TIMESTAMP можно форматировать с помощью функции date_format (см. руководство по mysql). Используйте его, и не форматируйте данные через php - это не просто "самодеятельность", а ещё и растрата системных ресурсов.
* По возможности минимально используйте LEFT JOIN для объединения таблиц. Это весьма трудоёмкая операция для базы данных.
* Там, где можно, используйте идентификаторы - выборка данных при указании ключевого поля происходит быстрее, чем при указании обычного.
* Вместо "WHERE id=1 OR id=3 OR id=232" можно использовать встроенную функцию IN: "WHERE id IN (1,3,232)".
* Если нужен текстовый поиск, осторожней со знаком "%". Во всяком случае, запросы типа somefield LIKE '%a%' лучше не делать - опять же слишком трудоёмкая операция. По крайней мере, надо фильтровать слова и отрезать те, которые короче 3 символов.
* Используйте минимум необходимых полей в запросе. "SELECT * FROM sometable" выполняется медленнее, чем "SELECT id FROM sometable", тем более если в таблице много данных. Для подсчёта количества строк в таблице вообще (или подпадающих под некоторое условие) достаточно одного поля.
* Разбивайте данные на страницы, используя оператор LIMIT. Это экономит время выполнения запроса и уменьшает объем страницы, которую получает пользователь.

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

кстати, новость услышал от сотрудника пару дней назад, начиная с версии MySQL 5.5 тип хранилища по умолчанию будет InnoDB :)

P.S.: Согласитесь, это лучше чем доставать левое ухо правой рукой на php, когда у вас в таблице дата хранится типом DATETIME:
SELECT *, DATE_FORMAT(`date`, '%d.%m.%Y') AS f_date FROM `table1`

пятница, 2 апреля 2010 г.

четверг, 1 апреля 2010 г.

Про СУБД MySQL и хранилище InnoDB, и про иерархические структуры =)

Не поверите, я искал и нашёл то, что хотел :D

Предисловие

Я пишу одно веб-приложение на PHP, которое использует MySQL в качестве СУБД и одна из задач этого приложения - создание, редактирование, удаление и вкладывание неких категорий друг в друга. Понятно, что данные о категориях должны храниться иерархически.

Не долго думая я построил одну таблицу для своих категорий и написал функцию на PHP которая может рекурсивно вычитывать "дерево" категорий.

Суть таблицы в том, что есть идентификатор поля (id) и идентификатор "родителя" (pid), в поле pid мы записываем id родителя.

Вчера добавлял в своё приложение возможность удалять категории, а т.к. у каждой категории могут быть свои дети, внуки, правнуки и т.п., логично удалять их тоже. Сказано - сделано. Продемонстрировал свой 40-а минутный труд сотруднику на что он мне сказал: "А зачем ты удаляешь на уровне программы, удаляй записи на уровне СУБД". Я на несколько секунд оторопел, потому что в голову даже такая мысль и не приходила, после чего спросил: "подскажи, что загуглить?". Он ответил: "delete cascade или foreign key". И начались поиски...

InnoDB вместо MyISAM

первое куда я попал это конечно dev.mysql.com:
http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html
после чего я понял, что мне нужно понять, что такое "InnoDB" :)))
следующая полезная ссылка для меня была на википедии. Там же нашёл ссылку на статью, которая вкратце и доступно объясняет что такое InnoDB, MyISAM, в чём разница и с чем их лучше кушать:
"Нужно ли переходить с MyISAM на InnoDB?"
после чего обратно курить доки по mysql, потом опять гуглить, в итоге, по запросу "древовидная иерархия innodb" надыбал замечательную статью на opennet'e "Иерархические структуры данных и Doctrine"

Иерархические структуры

В первую очередь, хочу выразить огромную благодарность Михаилу Стаднику, автору статьи, за огромный труд при написании статьи.

В данной статье очень подробно рассмотрено 3 основных подхода в организации хранения деревьев в реляционных БД:

* Список смежных вершин (Adjacency List)


* Вложенное множество (Nested Set)


* Материализованный путь (Materialized Path)

Также очерчены все достоинства и недостатки этих методов. И всё это подкреплено множеством примеров запросов. А особенно порадовали тесты на производительность.



В общем, всем кому пришлось столкнутся с "деревьями" - рекомендую. Статья - супер :)