Manipulate Results in GridView RowDataBound or Directly in SQL?

Question

Hello to everybody that is smarter than me!

I have a curious question about efficiency. Say I have a field on a database that is just a numeric digit that represents something else. Like, a value of 1 means the term is 30 days.

Would it be better (more efficient) to code a SELECT statement like this...

SELECT
    CASE TermId
        WHEN 1 THEN '30 days'
        WHEN 2 THEN '60 days'
    END AS Term
FROM MyTable

...and bind the results directly to the GridView, or would it be better to evaluate the TermId field in RowDataBound event of the GridView and change the cell text accordingly?

Don't worry about extensibility or anything like that, I am only concerned about the differences in overall efficiency. For what it's worth, the database resides on the web server.

I appreciate your response, even if it is completely useless.

Answer 1

For a number of reasons, I would process the translation in the grid view.

Reason #1: SQL resource is shared. Grid is distributed. Better scalability.

Reason #2: Lower bandwidth to transmit a couple integers vs. strings.

Reason #3: Code can be localized for other languages without affecting the SQL Server code.

Answer 2

Efficiency probably wouldn't matter here - code maintainability does though. Ask yourself - will these values change? What if they do? What would I need to do after 2 years of use if these values change? If it becomes evident that scripting them in SQL would mean better maintainability (easier to change), then do it in a stored Procedure. If it's easier to change them in code later, then do that. The benefits from doing either are quite low, as the code doesn't look complex at all.

Answer 3

A field in a database table called TermID would imply itself to represent a foreign key to another table (perhaps called "Term").

If this is the case, then perhaps that table has (or should have), a Description field which could hold the "30 days" text. You could/should join to this table to retrieve the descriptive text.

While this join might not improve efficiency, it it a light weight enough join to not get in the way.