Berekeningen doen in MySQL versus PHP

Ik zou spelen op de sterke punten van elk systeem.

Aggregatie-, join- en filterlogica hoort uiteraard thuis in de datalaag. Het is sneller, niet alleen omdat de meeste DB-engines 10+ jaar aan optimalisatie hebben om precies dat te doen, maar u minimaliseert ook de gegevens die tussen uw DB en webserver worden verschoven.

Aan de andere kant hebben de meeste DB-platforms die ik heb gebruikt een zeer slechte functionaliteit voor het werken met individuele waarden. Dingen zoals datumopmaak en stringmanipulatie zuigen gewoon in SQL, je kunt dat werk beter in PHP doen.

Gebruik in principe elk systeem waarvoor het is gebouwd.

In termen van onderhoudbaarheid, zolang de scheiding tussen wat waar gebeurt duidelijk is, zou het scheiden van deze naar soorten logica niet veel problemen moeten opleveren en zeker niet genoeg om de voordelen uit de weg te ruimen. Naar mijn mening gaat de duidelijkheid en onderhoudbaarheid van code meer over consistentie dan over het op één plek zetten van alle logica.

Re:specifieke voorbeelden...

Ik weet dat dit niet is wat u ook bedoelt, maar datums zijn bijna een speciaal geval. U wilt ervoor zorgen dat alle datums die door het systeem worden gegenereerd, op de webserver OF in de database worden gemaakt. Anders doen zal een aantal verraderlijke bugs veroorzaken als de db-server en webserver ooit zijn geconfigureerd voor verschillende tijdzones (ik heb dit zien gebeuren). Stel je voor, je hebt bijvoorbeeld een createdDate kolom met een standaard getDate() dat wordt toegepast op insert door de DB . Als u dan een record zou invoegen, met behulp van een datum gegenereerd in PHP (bijv. date("Y-m-d", time() - 3600) , records selecteert die in het afgelopen uur zijn gemaakt, krijgt u mogelijk niet wat u verwacht. Wat betreft op welke laag je dit moet doen, ik zou de voorkeur geven aan de DB, zoals in het voorbeeld, je kunt kolomstandaarden gebruiken.
Voor de meeste apps zou ik dit in PHP doen. Het combineren van voornaam en achternaam klinkt eenvoudig totdat je je realiseert dat je daar soms ook aanhef, titels en middelste initialen nodig hebt. Bovendien kom je vrijwel zeker in een situatie terecht waarin je een voornaam, achternaam EN een combinatie van aanhef + voornaam + achternaam wilt. Als je ze aan de DB-kant samenvoegt, betekent dit dat je uiteindelijk meer gegevens verplaatst, hoewel het eigenlijk vrij klein is.
Hangt ervan af. Zoals hierboven, als je ze ooit afzonderlijk wilt gebruiken, kun je ze qua prestaties beter apart uittrekken en aaneenschakelen wanneer dat nodig is. Dat gezegd hebbende, tenzij de datasets waarmee je te maken hebt enorm zijn, zijn er waarschijnlijk andere factoren (zoals, zoals je al zei, onderhoudbaarheid) die meer van belang zijn.

Een paar vuistregels:

Het genereren van incrementele id's zou in de DB moeten gebeuren.
Persoonlijk vind ik mijn standaard die door de database wordt toegepast goed.
Bij het selecteren moet alles wat het aantal records vermindert, door de database worden gedaan.
Het is meestal goed om dingen te doen die de grootte van de dataset aan de DB-zijde verkleinen (zoals met het stringvoorbeeld hierboven).
En zoals je zegt; bestellen, aggregatie, subquery's, joins, enz. moeten altijd aan de DB-zijde staan.
We hebben er ook nog niet over gesproken, maar triggers zijn meestal slecht/noodzakelijk.

Er zijn een paar belangrijke afwegingen waarmee u te maken krijgt en de balans hangt echt af van uw toepassing.

Sommige dingen moeten absoluut-elke keer-altijd in SQL worden gedaan. Met uitzondering van enkele uitzonderingen (zoals de datums) voor veel taken, kan SQL erg onhandig zijn en je met logica achterlaten op afgelegen plaatsen. Wanneer u in uw codebase zoekt naar verwijzingen naar een specifieke kolom (bijvoorbeeld) is het is gemakkelijk om die in een weergave of opgeslagen procedure te missen.

Prestaties zijn altijd een overweging, maar afhankelijk van je app en het specifieke voorbeeld misschien niet zo'n grote. Uw zorgen over onderhoudbaarheid zijn waarschijnlijk zeer terecht en sommige van de prestatievoordelen die ik heb genoemd zijn zeer gering, dus pas op voor voortijdige optimalisatie.

Ook als andere systemen rechtstreeks toegang hebben tot de DB (bijvoorbeeld voor rapportage of import/export), profiteert u van meer logica in de DB. Als u bijvoorbeeld gebruikers rechtstreeks uit een andere gegevensbron wilt importeren, zou in SQL zoiets als een e-mailvalidatiefunctie herbruikbaar zijn.

Kort antwoord:het hangt ervan af. :)