Отправляет email-рассылки с помощью сервиса Sendsay

Клуб профессиональных программистов

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Килограмм килобайтов" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Декабрь 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
RXL

Статистика

1.297 подписчиков
-1 за неделю
←   Все выпуски   →

Клуб профессиональных программистов :: Выпуск #132


Клуб профессиональных программистов «Весельчак У»
Информационная рассылка сайта и форума.  Выпуск 132.  29 декабря 2011 г.

Здравствуйте, уважаемые читатели!



Сегодня предлагаем вам прочесть фрагмент статьи «MySQL. Деревья. Добавление материализованного пути к паре id—parent_id», написанную по мотивам статьи «SQLite. Деревья. Добавление материализованного пути к паре id—parent_id.».



Приятного чтения! Прощаемся с Вами до следующего выпуска.


С уважением, команда Клуба.


MySQL. Деревья. Добавление материализованного пути к паре id—parent_id.

После публикации моей статьи «SQLite. Деревья. Добавление материализованного пути к паре id—parent_id» один из читателей попросил меня «портировать» алгоритм на MySQL. Я не возражал и в данной статье попытаюсь это сделать.


Обзор различий


MySQL очень сильно отличается от SQLite. Прежде всего, это разные сегменты рынка: SQLite позиционируется только для встраиваемых баз данных, а MySQL, в основном, позиционируется для web-решений, хотя встречается и в других применениях, включая встраиваемые. Существенные различия есть и в возможностях этих СУБД. Причем, сказать, что одна СУБД лучше другой тоже нельзя. Перечислю важные для данной статьи стороны:

  • SQLite поддерживает транзакционность «в базе». MySQL для этого требует использование формата InnoDB, хотя наиболее популярным является формат MyISAM.
  • Поддержка внешних ключей реализована в обеих СУБД, но в SQLite на текущий момент есть нарекания.
  • В SQLite отсутствует язык пользовательских процедур и нет переменных, что ограничивает возможности триггеров и вынуждает искать обходные пути. В MySQL этот язык достаточно развит, чтобы описать сложный алгоритм обработки, но тоже есть отдельные недостатки. Например, операторы выдачи исключений появились лишь в версии 5.5, когда как на момент написания статьи наиболее распространенные для хостингов версии — 5.0 и 5.1.
  • В MySQL на одно событие можно установить только один триггер, когда как в SQLite таких триггеров может быть несколько.
  • В SQLite допустимо перекрывать операции чтения и обновления одной и той же таблицы в одном операторе. Причем, можно даже изменять (в том числе добавлять и удалять) строки той же таблицы в назначенных на нее триггерах. MySQL ничего такого не допускает.

Реализация


Из-за перечисленных особенностей MySQL (невозможность в триггере обновлять «свою» таблицу) пришлось вынести поле материализованного пути в отдельную таблицу. Естественно, делать это пришлось с копией id. По той же причине удаление зависимых узлов поручено внешним ключам. Для активации внешних ключей и корректной работы триггеров также необходима поддержка транзакций — по этому используем для таблиц движок InnoDB.

Для статьи я буду использовать MySQL версии 5.5. В MySQL 5.0 и 5.1 оператор SIGNAL нужно заменить на чтение несуществующей таблицы: это приводит к исключению. В имени таблицы (длиной до 64 символов) можно кратко передать смысл исключения.


...



Полностью прочитать статью можно на нашем сайте, в разделе «Базы данных::MySQL».
В избранное