Sql Processing против ASP.NET Runtime обработка

Question

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

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

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 не одинаков для разных элементов. 1012 *

Answer 1

В целом, рекомендуется переносить как можно больше обработки с Sql Server в приложение

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

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

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

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

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

Answer 2

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

Для SQL не подходят такие вещи, как множественная регрессия и матричная инверсия.

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

Answer 3

Я рекомендую нормализовать вашу таблицу, чтобы убрать более 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, ...)

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

---

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

Answer 4

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