Provádění výpočtů v MySQL vs PHP

Hrál bych na silné stránky každého systému.

Logika agregace, spojování a filtrování samozřejmě patří k datové vrstvě. Je to rychlejší, nejen proto, že většina enginů DB má více než 10 let optimalizace, aby to dokázaly, ale minimalizujete přesun dat mezi vaší DB a webovým serverem.

Na druhou stranu většina DB platforem, které jsem používal, má velmi špatnou funkčnost pro práci s jednotlivými hodnotami. Věci jako formátování data a manipulace s řetězci prostě nasávají SQL, je lepší to dělat v PHP.

V zásadě používejte každý systém k tomu, k čemu je vytvořen.

Pokud jde o udržovatelnost, pokud je rozdělení mezi tím, co se kde děje, jasné, jejich rozdělení na typy logiky by nemělo způsobovat velké problémy a rozhodně ne dost na to, aby se zbavily výhod. Podle mého názoru je srozumitelnost kódu a udržovatelnost více o konzistenci než o umístění veškeré logiky na jedno místo.

Re:konkrétní příklady...

Vím, že to taky není to, o čem mluvíš, ale data jsou téměř speciální případ. Chcete se ujistit, že všechna data generovaná systémem jsou vytvořena buď na webovém serveru NEBO v databázi. Jinak způsobí nějaké zákeřné chyby, pokud jsou db server a webový server nakonfigurovány pro různá časová pásma (viděl jsem to). Představte si například, že máte createdDate sloupec s výchozí hodnotou getDate() který je aplikován na vložku DB . Pokud byste pak vložili záznam, pomocí data vygenerovaného v PHP (např. date("Y-m-d", time() - 3600) , vyberte záznamy vytvořené za poslední hodinu, možná nedostanete to, co očekáváte. Pokud jde o to, na které vrstvě byste to měli udělat, upřednostnil bych DB, protože v příkladu vám umožňuje používat výchozí hodnoty sloupců.
U většiny aplikací bych to udělal v PHP. Kombinace křestního jména a příjmení zní jednoduše, dokud si neuvědomíte, že tam občas potřebujete pozdravy, tituly a iniciály uprostřed. Navíc se téměř určitě dostanete do situace, kdy budete chtít po uživateli jméno, příjmení A kombinovaný pozdrav + jméno + příjmení. Jejich zřetězení na DB znamená, že přesunete více dat, i když ve skutečnosti je to docela malé.
Závisí Jak je uvedeno výše, pokud je někdy budete chtít používat samostatně, z hlediska výkonu je lepší je vytáhnout samostatně a v případě potřeby je zřetězit. To znamená, že pokud nejsou datové sady, se kterými se zabýváte, obrovské, pravděpodobně existují další faktory (jako, jak jste zmínil, udržovatelnost), které mají větší význam.

Několik základních pravidel:

Generování přírůstkových ID by mělo probíhat v databázi.
Osobně se mi líbí moje výchozí nastavení, které používá DB.
Při výběru by vše, co snižuje počet záznamů, mělo provést DB.
Obvykle je dobré dělat věci, které zmenšují velikost datové množiny na straně DB (jako u výše uvedeného příkladu řetězců).
A jak říkáš; řazení, agregace, dílčí dotazy, spojení atd. by měly být vždy na straně DB.
Také jsme o nich nemluvili, ale spouštěče jsou obvykle špatné/nezbytné.

Existuje několik zásadních kompromisů, kterým zde čelíte, a rovnováha skutečně závisí na vaší aplikaci.

Některé věci by se rozhodně – vždy – vždy měly dělat v SQL. Vyloučení některých výjimek (jako je datum) pro mnoho úloh SQL může být velmi neohrabané a může vám zanechat logiku mimo mísu. Při hledání odkazů na konkrétní sloupec (například) v kódové základně je snadno přehlédnete ty, které jsou obsaženy v pohledu nebo uložené proceduře.

Výkon je vždy na zvážení, ale v závislosti na vaší aplikaci a konkrétním příkladu možná ne tak velký. Vaše obavy ohledně udržovatelnosti a pravděpodobně velmi opodstatněné a některé z výkonnostních výhod, které jsem zmínil, jsou velmi malé, takže si dejte pozor na předčasnou optimalizaci.

Také, pokud jiné systémy přistupují přímo k DB (např. pro vytváření sestav nebo importy/exporty), budete mít prospěch z větší logiky v DB. Pokud například chcete přímo importovat uživatele z jiného zdroje dat, v SQL je implementováno něco jako funkce ověření e-mailu, kterou lze opakovaně použít.

Krátká odpověď:záleží. :)