Het hangt van veel factoren af, maar het belangrijkste is:
- complexiteit van berekeningen (doe liever complexe crunches op een app-server, omdat dat uit uitschaalt; in plaats van een db-server, die opschaalt )
- volume aan gegevens (als u veel gegevens moet benaderen/aggregeren, bespaart u bandbreedte door dit op de db-server te doen, en schijf io als de verzamelingen binnen indexen kunnen worden gedaan)
- gemak (sql is niet de beste taal voor complex werk - vooral niet geweldig voor procedureel werk, maar erg goed voor set-gebaseerd werk; waardeloze foutafhandeling echter)
Zoals altijd, als je doe breng de gegevens terug naar de app-server, het minimaliseren van de kolommen en rijen is in uw voordeel. Ervoor zorgen dat de zoekopdracht is afgestemd en op de juiste manier is geïndexeerd, zal beide scenario's helpen.
Herhaal uw notitie:
en loop dan door de records
Looping door middel van records is bijna altijd het verkeerde om te doen in sql - het schrijven van een set-gebaseerde bewerking heeft de voorkeur.
Als algemene regel , Ik geef er de voorkeur aan om de taak van de database tot een minimum te beperken "deze gegevens opslaan, deze gegevens ophalen" - er zijn echter altijd voorbeelden van scenario's waarbij een elegante query op de server veel bandbreedte kan besparen.
Bedenk ook:als dit rekenkundig duur is, kan het dan ergens in de cache worden opgeslagen?
Als u een nauwkeurige . wilt "wat is beter"; codeer het in beide richtingen en vergelijk het (merk op dat een eerste versie van een van beide waarschijnlijk niet 100% is afgestemd). Maar houd daarbij rekening met typisch gebruik:als het in werkelijkheid 5 keer (afzonderlijk) tegelijk wordt aangeroepen, simuleer dat dan:vergelijk niet slechts een enkele "1 van deze versus 1 van die".