Использование хранимых процедур для расчетов - PullRequest
1 голос
/ 06 октября 2008

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

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

Фактический вопрос, который у меня возник, касается способа получения данных. Мне нужно сделать несколько разных расчетов с данными клиентов. Лучше ли иметь разные хранимые процедуры, чтобы выполнять вычисления на основе номера клиента и возвращать результат, или лучше, если бы хранимая процедура возвращала всю информацию о клиенте и выполняла вычисления в сценарии?

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

Ответы [ 10 ]

3 голосов
/ 06 октября 2008

Интересно, что люди хранилища данных делают это постоянно. Они часто используют простейший из возможных SQL (SELECT SUM / COUNT ... GROUP BY ...) и выполняют работу вне базы данных в инструментах написания отчетов.

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

1 голос
/ 06 октября 2008

Это действительно зависит от операций. Вполне возможно иметь эти вещи как вычисляемые столбцы в базе данных, предварительно рассчитывать их в представлениях или SP (или использовать UDF), рассчитывать их отдельно и сохранять во время ETL или фазы суммирования, или позволить клиенту сделать это.

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

1 голос
/ 06 октября 2008

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

1 голос
/ 06 октября 2008

Я думаю, что многое из этого связано с данными и операциями, которые вы делаете. Обычно я нахожу, что при выполнении вычислений, которые уменьшают размер возврата из БД (группировки и агрегаты), гораздо эффективнее делать это в БД. Когда вы начинаете делать другие расчеты, это не так очевидно.

0 голосов
/ 16 октября 2012

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

Любой способ расчета данных с использованием данных других таблиц.

СУММА мы можем сделать в SP,

Declare @SUMAmount decimal(12,3) 

- также объявить @A, @B и т. Д.

Select @SUMAmount= SUM(ISNULL(@A,0)+ISNULL(@B,0)+ISNULL(@C,0)+ISNULL(@D,0))

Select @SUMAmount= SUM((ISNULL(@A,0)+ISNULL(@B,0))*(ISNULL(@C,0)-ISNULL(@D,0)))

Согласно вашему требованию вы можете дать условие.

ISNULL использует для проверки, являются ли данные NULL, а затем возвращает 0. Вычисление с нулевым значением невозможно, поэтому лучше дать условие ISNULL.

Select A,B,SUM(C),D From TableName
Where SUM(C)>0
Group By A,B,D

Здесь есть как агрегатные, так и неагрегированные функции, поэтому вы должны использовать Group By. Вы можете получить значения в соответствии с вашим условием, например: «Где SUM (C)> 0». Имея также вы можете использовать здесь после Group By.

 Declare @TotalNoofDays  int
 @TotalNoofDays = DATEDIFF(d, fromdate, todate) 

Использование для поиска количества дней с использованием этой функции.

Вы можете использовать условие, как,

if @DueAmount >=0
BEGIN
IF @DiscountFlag = 1
BEGIN
SET @DueIntAmount   = 0
END
ELSE
   BEGIN
     SET @DueIntAmount  = ((@DueAmount*(@IntRateOnDue/100))/365)*@NoofDays
   END
  SET @ExcessInterestAmount = 0
END
ELSE
BEGIN
SET @DueIntAmount   = 0
SET @ExcessInterestAmount = ((@DueAmount*(@IntRateOnDeposit/100))/365)*@NoofDays
 END

Как и вычисления, которые вы можете выполнить в хранимой процедуре.

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

 Create Proc NewLearningProcedure
 (
   @Name Varchar(50),
   @Date DateTime
 )
 AS
 Begin

Declare @Temp Table
(
   ID int Identity(1,1),
   Name Varchar(50),
   Date DateTime
)

Insert Into @Temp
Select @Name,@Date

Declare @i int
set @i=10

While @i>0
Begin
  Insert Into @Temp
  Select @Name+CAST(@i as varchar(50)),@Date

  Set @i=@i-1
 End


 Select * from @Temp


 End

Как будто вы можете делать что-либо с помощью хранимой процедуры.

0 голосов
/ 07 октября 2008

Все, что вы говорите, наводит меня на мысль, что вам следует подумать о хранении ваших данных. Если вы обнаружите, что пишете сложные объединения в системе OLTP и нуждаетесь в дополнительных вычислениях (и это звучит так, как будто вы), то денормализация ваших данных и хранение предварительно вычисленных агрегатов на складе значительно упростит вашу жизнь.

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

0 голосов
/ 06 октября 2008

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

0 голосов
/ 06 октября 2008

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

Также с точки зрения масштабируемости дублирование серверов приложений не так дорого, как дублирование серверов баз данных.

Это не значит, что хранимые процедуры не могут быть использованы. Генерация отчетов была бы идеальным кандидатом для вычислений, выполненных с использованием хранимых процедур.

0 голосов
/ 06 октября 2008

Из вашего вопроса звучит, что наиболее эффективным способом было бы выполнить все вычисления в SP и вернуть единственный (?) Результат в ваш скрипт.

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

0 голосов
/ 06 октября 2008

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

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

Редактировать ~ Посмотрите также на ваши расчеты. Некоторые из них могут быть выгружены для клиентов переднего плана.

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