Манипулировать результатами в GridView RowDataBound или непосредственно в SQL?

Question

У меня есть любопытный вопрос об эффективности. Скажем, у меня есть поле в базе данных, которое представляет собой просто цифровую цифру, которая представляет что-то еще. Например, значение 1 означает, что срок составляет 30 дней.

Было бы лучше (более эффективно) кодировать оператор SELECT, как этот ...

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

... и привязать результаты непосредственно к GridView, или было бы лучше оценить поле TermId в событии RowDataBound GridView и соответственно изменить текст ячейки?

Не беспокойтесь о расширяемости или о чем-то подобном, меня интересуют только различия в общей эффективности. Что бы это ни стоило, база данных находится на веб-сервере.

Answer 1

Эффективность, вероятно, здесь не имеет значения, хотя сопровождение кода имеет значение. Спросите себя - изменятся ли эти значения? Что делать, если они делают? Что мне нужно сделать после 2 лет использования, если эти значения изменятся? Если становится очевидным, что написание сценариев в SQL будет означать лучшую ремонтопригодность (легче изменить), сделайте это в хранимой процедуре. Если потом легче изменить их в коде, сделайте это. Выгоды от этого достаточно малы, так как код совсем не выглядит сложным.

Answer 2

Поле в таблице базы данных, называемое TermID, подразумевает, что оно представляет внешний ключ для другой таблицы (возможно, называемой «Term»).

Если это так, то, возможно, эта таблица имеет (или должна иметь) поле Описание, которое может содержать текст «30 дней». Вы можете / должны присоединиться к этой таблице, чтобы получить описательный текст.

Хотя это объединение не может улучшить эффективность, если оно достаточно легкое, чтобы не мешать.

Answer 3

По ряду причин я бы обработал перевод в виде сетки.

Причина № 1: ресурс SQL является общим. Сетка раздается. Лучшая масштабируемость.

Причина № 2: Более низкая пропускная способность для передачи пары целых чисел против строк.

Причина № 3: Код можно локализовать для других языков, не затрагивая код SQL Server.