Когда лучше перенести работу в СУБД, чем делать это в коде?

Хорошо, я справлюсь с этим: я лучше программист, чем в базах данных, и мне интересно, где размышления о «лучших практиках» лежат на предмет выполнения «простых» вычислений в запросе SQL по сравнению с код, такой как этот пример MySQL (я не писал его, я просто должен его поддерживать!) - возвращает имя пользователя и возраст пользователя на момент последнего события.

SELECT u.username as user, 
       IF ((DAY(max(e.date)) - DAY(u.DOB)) < 0 ,   
       TRUNCATE(((((YEAR(max(e.date))*12)+MONTH(max(e.date)))
       -((YEAR(u.DOB)*12)+MONTH(u.DOB)))-1)/12, 0),  
       TRUNCATE((((YEAR(max(e.date))*12)+MONTH(max(e.date))) -            
       ((YEAR(u.DOB)*12)+MONTH(u.DOB)))/12, 0)) AS age   
FROM users as u
JOIN events as e ON u.id = e.uid
...

По сравнению с «тяжелым» поднятием кода:

Запрос:

SELECT u.username, u.DOB as dob, e.event_date as edate
FROM users as u
JOIN events as e ON u.id = e.uid

код:

function ageAsOfDate($birth, $aod)
{    //expects dates in mysql Y-m-d format...
     list($by,$bm,$bd) = explode('-',$birth);
     list($ay,$am,$ad) = explode('-',$aod);

     //Insert Calculations here 
     ...
     return $Dy; //Difference in years
}

echo "Hey! ". $row['user'] ." was ". ageAsOfDate($row['dob'], $row['edate']) . " when we last saw him."; 

Я почти уверен, что в таком простом случае, как этот, это не будет иметь большого значения (кроме ползучего чувства ужаса, когда мне придется вносить изменения в запросы, подобные первому), но я думаю, что это проясняет то, что я ' ищу

Благодарность!

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

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

Каждый случай отличается

Это логика ...

• нужен другим клиентам? СУХОЙ: в базе данных
• используется для дальнейшей обработки? например, сортировка по возрастанию по убыванию: в базе данных
• требуются региональные настройки? дд / мм / гггг или мм / дд / гггг: в клиенте
• часто используется? Зачем вычислять это снова и снова: используйте вычисляемый и сохраненный столбец в базе данных

В этом случае я мог бы использовать вычисляемый и постоянный столбец в базе данных

Могло быть и хуже: вы могли бы иметь это в базе данных:

"Hey! ". u.username." was ". <datecalc>. " when we last saw him."

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

Для манипулирования данными это обмен. Если база данных тратит сравнимое количество циклов процессора на код внешнего интерфейса, выполняя то же самое - учитывая, что объем передаваемых данных примерно эквивалентен), то не имеет значения, где. Тогда сделайте это там, где у вас есть наибольший опыт программирования. Зачастую вы можете получить ОЧЕНЬ долгий путь с тщательным отбором, и это может быть очень полезно.

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

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

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

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