Коли краще завантажувати роботу в RDBMS, а не робити це в коді?


12

Гаразд, я довідаюсь про це: я кращий кодер, ніж я в базах даних, і мені цікаво, де лежать думки про "кращі практики" щодо того, щоб робити "прості" обчислення в 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."; 

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

Дякую!


1
Це гарне запитання - я натрапив на те саме питання.
Майкл К

Ось хороший приклад, коли цього не робити: Calendar.sql (Так, це моє жахливість, так, це була погана ідея, і ні, це не повільно.)
greyfade

Ви, гортаючи богів ... Я обділяю, що MD5 за те, що виходить "CthulhuFhtagn"
GeminiDomino

Відповіді:


13

Ви хочете виконати всі операції, засновані на наборі даних у базі даних, з міркувань продуктивності. Тож функції агрегації, функції сортування, приєднання тощо.

Цей віковий розрахунок я б зробив у коді. Єдиною причиною, коли я можу робити щось подібне в запиті до бази даних, є те, що для цього потрібні багато стовпців, які я б інакше не вибрав, що насправді може скласти достатню кількість даних, щоб суттєво уповільнити запит. Вибір кількох цілих значень не призведе до суттєвої різниці в продуктивності. І навіть якщо це буде помірною різницею в роботі, я буду упереджено зберігати цю логіку в коді програми.


Я згоден. Код, який відповідає значень для цілей відображення, повинен міститись у коді додатка.
TehShrike

4

Кожен випадок різний

Чи є логіка ...

  • потрібні інші клієнти? СУХА: в базі даних
  • використовується для подальшої переробки? наприклад, сортувати за віком за убуванням: у базі даних
  • вимагає регіональних налаштувань? dd / mm / yyyy або mm / dd / yyyy: у клієнта
  • використовується часто? Навіщо обчислювати це знову і знову: використовуйте обчислювані та збережені стовпці в базі даних

У цьому випадку я можу використовувати обчислюваний та збережений стовпець у базі даних

Це може бути гірше: у вас це може бути в базі даних:

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

3

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

Для обробки даних це торгівля. Якщо база даних витрачає порівнянну кількість циклів процесора з вашим кодом frontend, роблячи те ж саме - враховуючи, що кількість переданих даних приблизно еквівалентна), то не має значення куди. Потім зробіть це там, де у вас найбільший обсяг програмного досвіду. Часто ви можете пройти ДУЖЕ довгий шлях при ретельному виборі, що може бути дуже корисно.


1

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

Апаратне забезпечення бази даних має значно більше ресурсів, ніж інші сервери, і ви не можете це змінити. Це може не стосуватися цієї конкретної ситуації, але, можливо, потрібно буде врахувати.

Є й інші програми, яким може знадобитися логіка поза кодом. Деякі інструменти для написання звітів можуть не використовувати веб-сервіс чи API. Ви можете скопіювати логіку або, якщо вважаєте, що вимоги можуть розходитися.


"Апаратне забезпечення бази даних має значно більше ресурсів, ніж інші сервери, і ви не можете це змінити." - так? Звідки взялися ці дві заяви?
Пітер Бауфтон

Я думаю, що Джефф може говорити про окремі сервери баз даних. Напевно, я мав би вказати, що я працюю здебільшого на налаштуваннях LA [MP] P.
GeminiDomino

1
Налаштування LAMP не є причиною відсутності окремого сервера баз даних, а також окремий сервер баз даних не є гарантією отримання більшої кількості ресурсів, або не в змозі змінити це.
Пітер Бауфтон

Грн. Тоді не впевнений.
GeminiDomino

@Peter Boughton, DB та додаток на одному сервері мають на порядок менше часу для підключення інтерфейсу і величини IO на всьому протязі, є реальні причини розміщення цих двох разом.
Черга Jé

0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.