Хранимая процедура MySQL против PHP-скрипта - PullRequest
8 голосов
/ 01 мая 2009

У меня есть сайт для оптового торговца ювелирными изделиями.

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

В настоящее время для веб-сайта вычисления выполняются с помощью функции php include, которая отлично работает в текущих условиях.

Существует около 10 000 товаров, но цены рассчитываются в режиме реального времени (т.е. при запросе веб-страницы). Расчеты просты, но их много (около 50+), и я беспокоюсь, что увеличение трафика может замедлить текущий скрипт.

Я занимаюсь редизайном сайта, и мне было интересно, будет ли полезно создать процедуру в MySQL для выполнения расчетов вместо этого.

Это скорее всего будет быстрее, чем текущий скрипт php? Кто-нибудь знает какую-нибудь хорошую справочную литературу по использованию процедур?

Ответы [ 4 ]

14 голосов
/ 01 мая 2009

Вот тест с хранимой процедурой против php.

http://mtocker.livejournal.com/45222.html

Хранимая процедура была медленнее в 10 раз.

Вы также можете посмотреть на это:

http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

8 голосов
/ 01 мая 2009

Если причина, по которой вы думаете об этом, связана с производительностью и масштабируемостью, я бы рекомендовал продолжить вычисления в PHP.

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

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

  • Может быть менее портативным. Хранимая процедура добавляет усилий, необходимых для развертывания нового экземпляра вашего приложения.
  • Они написаны на языке, отличном от PHP, поэтому разработчик PHP может не найти их легкими для понимания.
  • Может быть трудно держать их под контролем источника.

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

4 голосов
/ 01 мая 2009

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

Я бы порекомендовал кэшировать информацию, которую вы используете (и которую трудно понять, не зная, как вы это делаете), в памяти (возможно, используя memcached) и продолжать читать ее из PHP.

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

3 голосов
/ 01 мая 2009

Короче, держите их в php. Проще поддерживать.

Для текущего сайта вряд ли когда-либо случится проблема с производительностью, когда разница между скоростью calc в php и скоростью calc в базе данных когда-либо заметна. Если бы вы были, значит, что-то в корне не так с кодом сайта. (Это включает конвертацию валюты в режиме реального времени, если это делается).

Сказав это, обычно предпочитают хранить calc в PHP, так как его легче контролировать и отлаживать. Требуется, чтобы веб-кодеры немного знали базу данных, но обычно это не проблема. 90% ускорений кода происходит на 10% кода, и для dba было бы достаточно легко идентифицировать запросы, вызывающие загрузку db, если это когда-либо произошло.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...