PHP и базы данных: производительность представлений, функций и хранимых процедур

Question

Я работаю над веб-приложением PHP с PostgreSQL. Все запросы SQL вызываются из кода PHP. Я не видел ни просмотров, ни функций, ни хранимых процедур. Из того, что я узнал, всегда лучше использовать эти подпрограммы базы данных, поскольку они хранятся в базе данных с преимуществами:

• Инкапсуляция
• Абстракция
• Права доступа (ограничены администратором БД) и ответственность
• Избегать компиляции

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

В основном, когда в коде так много запросов "SELECT", почему бы не использовать Views?

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

Answer 1

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

Я написал и работал с кучей разных веб-приложений, но ни у одного из них не было миллиардов пользователей. Те, с хранимыми процедурами, неудобны. Те, у которых есть специальные SQL-запросы, выполняются достаточно быстро (используйте заполнители и другие рекомендации, чтобы избежать внедрения SQL-кода). Моя любимая абстракция базы данных (ORM), поэтому ваш код имеет дело с PHP-классами и объектами, а не напрямую с базой данных. Для этого я все чаще обращаюсь к фреймворку Symfony.

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

Answer 2

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

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

@ WolfmanDragon: Я не знаю, если взгляды по сути дела замедляют процесс; Ваш пробег может варьироваться, я полагаю, в зависимости от сложности представления и СУБД, которую вы используете. Кроме того, некоторые РСУБД позволяют вам материализовать часто используемые представления, поэтому доступ к ним осуществляется так же быстро, как и к базовой таблице.

Answer 3

I. Представления предлагают инкапсуляцию, но если они не будут тщательно разработаны, они могут замедлить работу приложения. Используйте с осторожностью.
II. При необходимости используйте функции, нет причин вставлять их, если они не нужны.
III. Хранимые процедуры - находка, используйте их везде, где есть статический запрос !!

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

Answer 4

Мы стараемся использовать функции, которые вы упомянули только там, где есть существенное преимущество

Будучи частью «Базы данных», они подпадают под «изменения схемы» , а не
«изменения исходного кода» , и, естественно, сложнее контролировать версию .

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