Обработка Sql против ASP.NET Обработка времени

Question

Я знаю, что в целом рекомендуется переместить как можно больше обработки с Sql Server в приложение (в моем случае ASP.NET). Однако что, если обработка на уровне приложения означает передачу еще 30 дополнительных параметров на сервер Sql. В этом случае стоит ли переместить обработку на сервер Sql?

Вот особая дилемма, с которой я столкнулся - какая процедура предложит лучшую производительность в целом?

CREATE PROCEDURE MyProc1 
    @id int 
AS BEGIN 
    UPDATE MyTable 
    SET somevalue1 = somevalue1 + 1, 
     somevalue2 = somevalue2 + 1, 
     somevalue3 = somevalue3 + 1, 
     ... 
     somevalueN = somevalueN + 1 
    WHERE id = @id 
END 

Или

CREATE PROCEDURE MyProc2 
    @id int, 
    @somevalue1 int, 
    @somevalue2 int, 
    @somevalue3 int, 
    ... 
    @somevalueN int 
AS BEGIN 
    UPDATE MyTable 
    SET somevalue1 = @somevalue1, 
     somevalue2 = @somevalue2, 
     somevalue3 = @somevalue3, 
     ... 
     somevalueN = @somevalueN 
    WHERE id = @id 
END 

Я использую управляемый хостинг, но я предполагаю, что это справедливо предположить, что Sql Server и среда выполнения ASP.NET находятся на одном компьютере, так что передача данных между два, вероятно, будут довольно быстрыми/пренебрежимыми (или это).

---

30 параметров в основном totalNumberOfRatings для разных предметов. Поэтому всякий раз, когда пользователь моего веб-приложения дает новый рейтинг для элемента itemN, totalNumberOfRatingsItemN увеличивается на 1. В большинстве случаев рейтинг будет присвоен нескольким элементам (но не обязательно всем), поэтому totalNumberOfRatings не одинаковы для разных элементов.

Answer 1

Я сделаю все возможное, что вы прочитали, что SQL Server не подходит для математики. Я думаю, что SQL вполне подходит для выполнения нескольких арифметических операций и агрегированных операций, таких как SUM. Можно точно сказать, что только реализация реализаций в реалистичных сценариях загрузки может сказать точно.

Что не подходит SQL, это такие вещи, как множественная регрессия и инверсия матрицы.

Перемещение инкременторов на уровень приложений звучит для меня как микро-оптимизация, которая вряд ли будет платить за себя. Реализовать логику для увеличения значений в каждом уровне, что делает код читаемым и поддерживаемым.

Answer 2

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

Answer 3

в целом это хорошая практика, чтобы двигаться как можно больше обработки, как можно дальше от Sql Server для приложения

Говорит кто? SQL Server хорош в некоторых вещах, не так хорош в других. Используйте свое мнение.

и "приложение", вы имеете в виду

• веб-страницы
• приложение-сервис слой
• автобусное предприятие компонент
• веб-сервис
• что-то еще?

Есть много вариантов ...

Что касается вашего конкретного вопроса, увеличивающийся 30 полеев кажется нелепым. Передача 30 парм кажется чрезмерной. Некоторый контекст в порядке ...

Answer 4

Я рекомендую нормализовать таблицу, чтобы исключить 30+ столбцов рейтингов. Вместо этого, рассмотреть вопрос о таблице с одним рейтинговыми колонками и имеющая одну строки для каждого отдельного элемента, например, так:

CREATE TABLE ItemRatings 
(
    myTableId INT NOT NULL, -- Foreign key 
    itemNumber INT NOT NULL, 
    itemRating INT 
); 

Вы можете затем увеличить кучу рейтингов сразу с запросом, как

UPDATE ItemRatings 
    SET itemRating = itemRating + 1 
WHERE myTableId = @id 
     AND itemNumber IN (@n1, @n2, @n3, ...) 

Что-то вроде этого, в любом случае. Я не совсем понимаю, как работают ваши таблицы, так как вы анонимизировали все имена, но, надеюсь, вы получите суть того, что я говорю.

Это, если вы не хотите или не можете нормализовать свою таблицу таким образом, я согласен с другими ответами. Это шесть из одного, полдюжины других. Лично я бы выбрал первый способ и позволил базе данных сделать все тяжелое поднятие. Конечно, как и во всех случаях, если производительность является ультракритической, то реальный ответ - не угадать; попробуйте оба способа и выйдите из своего секундомера!