Göra beräkningar i MySQL vs PHP

Jag skulle spela efter styrkorna i varje system.

Aggregerings-, sammanfognings- och filtreringslogik hör självklart hemma på datalagret. Det är snabbare, inte bara för att de flesta DB-motorer har 10+ års optimering för att göra just det, utan du minimerar data som flyttas mellan din DB och webbservern.

Å andra sidan har de flesta DB-plattformar jag har använt mycket dålig funktionalitet för att arbeta med individuella värden. Saker som datumformatering och strängmanipulation suger bara in SQL, det är bättre att du gör det i PHP.

Använd i princip varje system för vad det är byggt för att göra.

När det gäller underhållbarhet, så länge som uppdelningen mellan vad som händer var är tydlig, borde separering av dessa till typer av logik inte orsaka mycket problem och definitivt inte tillräckligt för att få ut fördelarna. Enligt min åsikt handlar kodtydlighet och underhållsbarhet mer om konsekvens än om att lägga all logik på ett ställe.

Re:specifika exempel...

Jag vet att det inte är det du syftar på men datum är nästan ett specialfall. Du vill se till att alla datum som genereras av systemet skapas antingen på webbservern ELLER databasen. Om du gör något annat kommer det att orsaka några lömska buggar om db-servern och webbservern någonsin är konfigurerade för olika tidszoner (jag har sett detta hända). Föreställ dig till exempel att du har ett createdDate kolumn med standardvärdet getDate() som tillämpas vid infogning av DB . Om du skulle infoga en post då, med ett datum genererat i PHP (t.ex. date("Y-m-d", time() - 3600) , välj poster som skapats under den senaste timmen, kanske du inte får vad du förväntar dig. När det gäller vilket lager du ska göra detta på, skulle jag föredra DB för, som i exemplet, den låter dig använda kolumnstandardinställningar.
För de flesta appar skulle jag göra detta i PHP. Att kombinera förnamn och efternamn låter enkelt tills du inser att du behöver hälsningar, titlar och mellaninitialer ibland också. Plus att du nästan definitivt kommer att hamna i en situation där du vill ha användarens förnamn, efternamn OCH en kombinerad hälsning + förnamn + efternamn. Att sammanfoga dem på DB-sidan innebär att du flyttar mer data, även om det egentligen är ganska litet.
Beror på. Som ovan, om du någonsin vill använda dem separat är det bättre prestandamässigt att dra ut dem separat och sammanfoga dem när det behövs. Som sagt, såvida inte de datauppsättningar du har att göra med är enorma, finns det förmodligen andra faktorer (som, som du nämner, underhållbarhet) som har större betydelse.

Några tumregler:

Generering av inkrementella ID bör ske i databasen.
Personligen gillar jag att min standard tillämpas av DB.
När du väljer ska allt som minskar antalet poster göras av databasen.
Det är vanligtvis bra att göra saker som minskar storleken på datasetets DB-sida (som med strängexemplet ovan).
Och som du säger; beställning, aggregering, underfrågor, kopplingar etc. bör alltid vara DB-sidan.
Vi har inte heller pratat om dem men triggers är vanligtvis dåliga/nödvändiga.

Det finns några centrala kompromisser du står inför här och balansen beror verkligen på din ansökan.

Vissa saker bör definitivt-varje gång-alltid göras i SQL. Exkludera vissa undantag (som datum-grejen) för många uppgifter SQL kan vara väldigt klumpig och kan lämna dig med logik i ur vägen. När du söker i din kodbas efter referenser till en specifik kolumn (till exempel) är det lätt att missa de som finns i en vy eller lagrad procedur.

Prestanda är alltid ett övervägande men, beroende på din app och det specifika exemplet, kanske inte en stor sådan. Dina farhågor om underhållsbarhet och förmodligen mycket giltiga och några av prestandafördelarna jag har nämnt är mycket små så akta dig för för tidig optimering.

Dessutom, om andra system får åtkomst till DB direkt (t.ex. för rapportering eller import/export) kommer du att dra nytta av att ha mer logik i DB. Till exempel, om du vill importera användare från en annan datakälla direkt, något som en e-postvalideringsfunktion skulle vara återanvändbar implementeras i SQL.

Kort svar:det beror på. :)