Бизнес-логика на PHP или MySQL?

Question

На сайте с разумным объемом трафика, будет ли иметь значение, если приложение / бизнес-логика записывается как хранимые процедуры, триггеры и представления, а не внутри самого кода PHP?

Как лучше всего помнить о масштабируемости?

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Будет ли доступ к той же базе данных с разных сайтов / веб Приложения? Будут ли сайты / приложения должны быть написаны в том же язык или на другом языке?

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

Что такое реляционные базы данных в в общем, хорошо и что такое MySQL хорошо для конкретно? Что такое PHP лучше всего в?

Это соображение довольно простое. Реляционные базы данных по всем направлениям и, в частности, в любом варианте SQL, отлично справятся со вставкой, обновлением и удалением данных. Как правило, они также хорошо обрабатывают транзакции ATOMIC. Однако большинство вариантов SQL (включая MySQL) не подходят для сложных вычислений, обработки дат на лету, доступа к файловой системе и т. Д.

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

Что вы наиболее знакомы / удобно ли пользоваться?

Очевидно, что имеет больше смысла использовать инструмент, с которым вы наиболее знакомы.

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

Answer 4

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

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

Answer 5

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

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

Answer 6

Мой POV, даже не имеющий большого опыта в разработке больших приложений, должен написать бизнес-логику в БД по некоторым причинам:

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

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

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

4 - Если вы когда-нибудь решите полностью изменить язык, на котором пишете приложение, (например, смерть языка), единственное, что нужно переписать, - это презентация и вызовы SP, а не бизнес-логика.

Я хотел бы узнать от других людей здесь, имеет ли смысл то, на что я указал, и если нет, то почему. Я нахожусь в той же ситуации, что и Сабин Малик, я думаю начать свой первый огромный проект и стремлюсь к SP, из-за того, что я написал. Поэтому пришло время исправить мой POV, если он не так корректен.

Answer 7

MySQL отстой в использовании передовых методов БД, это просто и быстро. PHP, будучи динамическим языком, делает обработку данных очень простой. Поэтому обычно имеет смысл использовать PHP.