Оператор SQL CASE и условные выражения в языке программирования - PullRequest
1 голос
/ 28 января 2009

Я прохожу некоторые старые хранимые процедуры на работе и постоянно сталкиваюсь

CASE MyColumn WHEN 'Y' THEN 'Yes' WHEN 'N' THEN 'No' ELSE 'Unknown' END

Становится еще хуже, когда это связано не со словом, а с цветом.

CASE MyColumn WHEN 'Y' THEN 'style="background-color:pink"' ELSE '' END

Причина, по которой это было сделано, заключалась в том, что для старых страниц ASP 1 все должно было быть встроено, но поскольку это такая большая система, невозможно идти в ногу с обновлением всех страниц.

Может ли кто-нибудь предоставить какие-либо действительные доказательства того, что использование SQL-запроса для условных операторов превосходит аналогичное использование в других языках, таких как C # или Java? Это хорошая практика для скорости? Должно ли быть возвращено простое значение, и уровень представления решает, что должно быть сделано?

Ответы [ 6 ]

3 голосов
/ 28 января 2009

Когда скорость важна, операторы SQL могут быть даже самыми быстрыми (я проведу тест), но для удобства сопровождения возврат простых значений на уровень представления (или что-то вроде бизнес-уровня) является лучшим вариантом. ,

[update] запустил несколько быстрых и грязных тестов (код ниже) и обнаружил, что вариант кода C # немного быстрее, чем вариант варианта SQL. Вывод: возврат «сырых» данных и манипулирование ими на уровне представления данных выполняется быстрее и удобнее в обслуживании.

-Edoode

Я получил 196288 строк с запросами ниже.

StringBuilder result = new StringBuilder();
using (SqlConnection conn = new SqlConnection(Settings.Default.Conn))
{                
    conn.Open();
    string cmd = "select [state], case [state] when 'ca' then 'california' else [state] end from member";
    SqlCommand command = new SqlCommand(cmd, conn);
    using (SqlDataReader reader = command.ExecuteReader(CommandBehavior.CloseConnection))
    {
        while (reader.Read())
        {                        
            result.AppendLine(reader.GetString(1));
        }
    }
}

C # вариант:

StringBuilder result = new StringBuilder();
using (SqlConnection conn = new SqlConnection(Settings.Default.Conn))
{

    conn.Open();
    string cmd = "select [state] from member";
    SqlCommand command = new SqlCommand(cmd, conn);
    using (SqlDataReader reader = command.ExecuteReader(CommandBehavior.CloseConnection))
    {
        while (reader.Read())
        {
            result.AppendLine(reader.GetString(0) == "ca" ? "california" : reader.GetString(0));
        }
    }

}

2 голосов
/ 28 января 2009

Я хотел бы включить такую ​​логику в операторы SQL. Что произойдет, если ваш движок базы данных изменится? Придется ли вам обновлять каждую инструкцию SQL до Oracle SQL? Что, если само хранилище изменяется, когда вы переходите на шину сообщений, файлы XML или вызов веб-службы ...

Похоже, вы храните информацию дисплея. В этом случае это часть модели данных. Пусть контроллер (в типичной схеме MVC ) выполняет условную логику. Слой представления не должен знать, что произошло, и хранилище может быть счастливым, просто храня данные.

0 голосов
/ 28 января 2009

Согласитесь на 100% о рефакторинге для размещения решений отображения на уровне представления (или как можно ближе).

CASE ... END в SQL все еще может использоваться, хотя, например, скажем, я хочу рассчитать процентную долю от общей стоимости всех заказов для внутренних клиентов. Я думаю, я был бы счастлив с

SELECT
  SUM(CASE domestic WHEN 'Y' THEN order_value ELSE 0 END) / SUM(order_value) AS pctg
FROM orders

как запрос. Если, конечно, кто-то не знает лучше.

0 голосов
/ 28 января 2009

С точки зрения производительности SQL, если вы возвращаете только несколько строк (или одну из них), это оказывает минимальное влияние, поскольку часть инструкции WHERE оценивается перед регистром (регистр выполняется только для строки, которые соответствуют где).

С точки зрения передового опыта, отображаемая информация не должна определяться в SQL. Возможно, возвращает тип темы, но, конечно, не скрытую информацию о стиле.

0 голосов
/ 28 января 2009

Это код в старом стиле, я не верю, что люди больше так кодируют (сейчас мы используем CSS)
Вы, вероятно, скоро увидите что-то, что станет наследием, которое будет переписано или заброшено

0 голосов
/ 28 января 2009

Может ли кто-нибудь дать какие-либо достоверные доказательства того, что использование SQL-запроса для условных операторов превосходит аналогичное использование в других языках, таких как C # или Java? Это хорошая практика для скорости? Должно ли быть возвращено простое значение, и уровень представления решает, что должно быть сделано?

Иногда (иногда) это просто помогает избежать дополнительного кодирования на уровне представления.

Как правило, если база данных и презентация разрабатываются одним человеком, это не имеет значения. Проблемы начинаются, когда работа становится общей. В этом случае вам, очевидно, нужен четко сформулированный контракт о том, что генерирует база данных и что принимает ASP.

Конечно, CSS принадлежит домену уровня представления, и он должен анализироваться ASP, а не жестко кодироваться в SQL.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...