My rule of thumb is to use DB functions for writes that require good data consistency, and for reads that are join heavy. For things like formatting and transf

My rule of thumb is to use DB functions for writes that require good data consistency, and for reads that are join heavy. For things like formatting and transforming data, I prefer to have that work done on the client (web browser) if it's for a presentation concern, or middle tier if it's for an integration. My theory there is "don't make the database work hard". Use it for what it's great at: fast reads and data consistency. DB functions and sprocs are a great way to reduce latency and load, and boost performance if used for the right things. An easy rule of thumb is that if my function isn't using SQL as the language, I need to really think about whether it belongs in the DB. That all being said, I do use udfs to construct JSON results for some reports also, when it makes sense based on the params and number of round-trips to the server it would cause in the middle or UI tiers. Even though it violates some of the things above, it's really damn convenient and usually limited to low-traffic queries.