Про сам фреймворк CakePHP я уже писал неоднократно. Для тех, кто хочет создать первое впечатление о фреймворке рекомендую прочитать статью Разработка веб-приложений с CakePHP. В статье я рассказывал, что из себя представляет данный фреймворк и какие основные принципы заложены в его основу.

Как я рассказывал в статье, CakePHP строится на модели MCV – модель-контроллер-отображение. Основой Вашего будущего представления будут именно модели, так как они обеспечивают взаимодействие приложение с базой данных. В качестве СУБД CakePHP может использовать большое количество баз данных, а также есть поддержка ODBC, что позволяет его подключать вообще ко всему-всему. Однако, каким бы универсальным решение не казалось, здесь есть свои ограничения.

Приведу небольшой пример. Работая над одним из последних своих проектов, мне нужно было извлекать данные из таблицы, которая была связана с еще 16. Таблицы базы данных я создал сразу при помощи утилиты phpMyAdmin, назначил внешние ключи. Модели также автоматически сгенерировал при помощи CakeBake.

При извлечении данных я заметил, что запрос, который формируется, занимает огромное количество времени для исполнения даже на пустой базе, тогда что можно говорить, сколько времени займет его выполнение на уже рабочей базе.

Этот момент стал для меня переломным и к моделированию базы данных я решил подойти немного с другой стороны.

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

Определимся, что такое внешний ключ. Когда мы связываем две таблицы, в каждой из таблиц есть свой первичный ключ, для CakePHP обычно это ID, в то время, как внешний ключ будет формироваться как имяТаблицы_ID.

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

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

Теперь проиллюстрирую все это при помощи удобной утилиты Mysql WorkBench, которую можно сказать с ее официального сайта. Создадим новую диаграмму, а в ней две таблицы. Я сделал это следующим образом:

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

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

Обратим внимание на правый нижний угол изображения, в нем находятся Foreign Key Options. Это и есть ограничения целостности, они как раз и отражают, как будет вести себя подчиненная таблица в случае изменения родительской, т.е. что нужно будет делать с записями в таблице Комментариев в случае изменения или удаления записи в таблице Статей.

За обновление и удаление отвечают ограничения On Update и On Delete. Они могут принимать следующие значения:

• NO ACTION – не предпринимать никаких действий, выбирается по умолчанию. Вне зависимости от манипуляций с основной таблицей, записи в дочерней будут сохраняться.
• SET NULL – в качестве значения внешнего ключа будет устанавливаться значение NULL, т.е. связанные записи будут попросту отваливаться от основной, т.е. ссылочная целостность будет нарушаться.
• CASCADE – каскадное удаление или обновление. В случае удаления записи из родительской таблицы, будут сразу удалены все записи из дочерних таблиц, т.е. при удалении Статьи будут также удалены все связанные с ней комментарии. Каскадное обновление значит, что при обновлении значения первичного ключа у основной записи, будут автоматически обновлены значения внешних ключей для связанных таблиц.

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

Похожие материалы:

• Создаем модели правильно – Часть 3
• Создаем модели правильно – Часть 2
• Кэширование вывода
• Разработка веб-приложений с CakePHP
• CakePHP, хитрые идентификаторы и таблицы маршрутов

Поделись с друзьями:

Присоединяйся ко мне: