Правете изчисления в MySQL срещу PHP

Бих играл на силните страни на всяка система.

Логиката за агрегиране, присъединяване и филтриране очевидно принадлежи на слоя данни. Това е по-бързо, не само защото повечето DB машини имат над 10 години оптимизация, за да правят точно това, но вие свеждате до минимум данните, премествани между вашата DB и уеб сървъра.

От друга страна, повечето DB платформи, които съм използвал, имат много лоша функционалност за работа с индивидуални стойности. Нещата като форматиране на дата и манипулиране на низове просто са гадни в SQL, по-добре е да вършите тази работа в PHP.

По принцип използвайте всяка система за това, за което е създадена.

По отношение на поддържаемостта, стига разделението между това, което се случва, където е ясно, разделянето им на типове логика не би трябвало да създава особени проблеми и със сигурност да не е достатъчно, за да извлече ползите. Според мен яснотата и поддръжката на кода са повече за последователност, отколкото за поставяне на цялата логика на едно място.

Re:конкретни примери...

1. Знам, че и ти не говориш за това, но датите са почти специален случай. Искате да сте сигурни, че всички дати, генерирани от системата, са създадени или на уеб сървъра, ИЛИ в базата данни. Ако направите друго, това ще доведе до някои коварни грешки, ако db сървърът и уеб сървърът някога са конфигурирани за различни часови зони (виждал съм това да се случва). Представете си, например, че имате createdDate колона със стойност по подразбиране getDate() който се прилага при вмъкване от БДа . Ако тогава трябваше да вмъкнете запис, като използвате дата, генерирана в PHP (напр. date("Y-m-d", time() - 3600) , изберете записи, създадени през последния час, може да не получите това, което очаквате. Що се отнася до кой слой трябва да направите това, бих предпочел DB за, както в примера, той ви позволява да използвате настройките на колоните по подразбиране.

2. За повечето приложения бих направил това в PHP. Комбинирането на собствено и фамилно име звучи просто, докато не осъзнаете, че понякога имате нужда от поздрави, заглавия и средни инициали. Освен това почти определено ще се окажете в ситуация, в която искате потребителско име, фамилия И комбиниран поздрав + собствено име + фамилия. Конкатенирането им от страна на DB означава, че в крайна сметка премествате повече данни, въпреки че всъщност това е доста незначително.

3. Зависи. Както по-горе, ако някога искате да ги използвате отделно, по-добре е по отношение на производителността да ги издърпате отделно и да ги конкатенирате, когато е необходимо. Въпреки това, освен ако наборите от данни, с които работите, са огромни, вероятно има други фактори (като, както споменавате, поддръжка), които имат по-голямо значение.

Няколко основни правила:

• Генерирането на допълнителни идентификатори трябва да се извършва в DB.
• Лично аз харесвам моето приложение по подразбиране от DB.
• Когато избирате, всичко, което намалява броя на записите, трябва да се извършва от БД.
• Обикновено е добре да се правят неща, които намаляват размера на набора от данни от страна на DB (като с примера за низове по-горе).
• И както казваш; подреждането, агрегирането, подзаявките, обединяването и т.н. винаги трябва да са от страна на DB.
• Освен това не сме говорили за тях, но задействанията обикновено са лоши/необходими.

Има няколко основни компромиса, с които се сблъсквате тук и балансът наистина зависи от вашето приложение.

Някои неща определено трябва да се правят – всеки път – винаги в SQL. Като изключим някои изключения (като нещото с датите) за много задачи SQL може да бъде много тромав и може да ви остави без логика. Когато търсите в кодовата си база препратки към конкретна колона (например) е лесно да пропуснете тези, които се съдържат в изглед или съхранена процедура.

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

Също така, ако други системи имат достъп до БД директно (например за отчитане или импортиране/експортиране), ще се възползвате от това да имате повече логика в БД. Например, ако искате да импортирате потребители директно от друг източник на данни, в SQL е внедрено нещо като функция за проверка на имейл, която може да се използва повторно.

Кратък отговор:зависи. :)