Есть ли какой-то класс алгоритмов, которые наиболее производительны на стороне СУБД?

Question

[Иван Мельников]

Есть ли какой-то класс алгоритмов, которые наиболее производительны на стороне СУБД?

Answer 1

[Владимир Коротенко]

Прям озадачили. Самая производительная стратегия это делать запросы только по индексам, и уменьшать "жадность" запроса.
Вторая это денормализация данных.
Третья использование prepared statement
Четвертая логика на стороне БД !!!!!!! очень опасная штука!!!!!!!!!!

Comments

[Иван Мельников]

А в чем именно опасность логики на СУБД? Что мешает создать хранимую процедуру, которая будет, например, выводить обсчитанные данные для графика?

[Владимир Коротенко]

Иван Мельников, Все это можно сделать в приложении, кроме того там вы получите большую гибкость и контроль за исполнением кода, и IDE не даст выстрелить в ногу.

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

[Иван Мельников]

Владимир Коротенко,

Все это можно сделать в приложении, кроме того там вы получите большую гибкость и контроль за исполнением кода, и IDE не даст выстрелить в ногу.

Но производительность будет ниже?

[Владимир Коротенко]

Иван Мельников,
Преждевременная оптимизация — корень всех зол. — статья «Structured Programming with go to Statements» в сборнике «Computing Surveys» (Vol. ... Premature optimization is the root of all evil. Преждевременная оптимизация — корень всех (или большинства) проблем в программировании.

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

[Армянское Радио]

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

Большая гибкость, под названием "бэкэнд опять навалили хрени, которую DBA вынужден разгребать?"

Контроль за исполнением кода невозможен на стороне СУБД? Что за сказка? Вам отключили отладчик plsql за неуплату?

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

[Владимир Коротенко]

Армянское Радио, Мы сейчас за суровый энтерпрайз или за веб?
И что это вы предлагаете в количестве десятков мегабайт таскать?
Я например имел в виду CRED операции по простому списку.
Например вот апи для получения статей, по вкусу можно прикрутить лимиты, сортировку и прочее.
В базе тоже не особо сложно, разве что метаполя для документа в json.

/api/authors/42
/api/articles/byauthor/42
/api/articles/byauthor/42/23
/api/articles/byauthor/42/23?type=pdf

Хотя для бизнеса бывает нужно что то посложнее, но реально, там черт ногу сломит.

То есть вы предлагаете что то типа такого?

/****** Object:  StoredProcedure [dbo].[Akkum_Year]    Script Date: 25.11.2019 9:55:29 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- ================================== ----- =======================================================
ALTER PROCEDURE [dbo].[Akkum_Year] 
	@KindProvisionCorpCode int 
AS
Begin
Declare 
@RowNum int,
@LicProvisionID int,
@Value_Year decimal(15,4),
@ObjCorpCode int,  
@Year int,
@Year_dt datetime,
@Format int
set Language russian -- для правильного формата даты
-- Выбрать из LicProvisionValue все даты, соотв. фактической добыче нефти
-- по месяцам
Declare Cur_F cursor for
SELECT  
lv.LicProvisionID, 
SUM(lv.Value) AS Value_Year, 
YEAR(lv.DateStart) AS Year, 
lv.ObjCorpCode
FROM   dbo.LicProvision lp INNER JOIN
dbo.LicProvisionValue lv ON lp.LicProvisionID = lv.LicProvisionID
GROUP BY lp.KindProvisionCorpCode, 
(lv.DateStart), 
lp.EntityID, 
lv.ObjCorpCode,
lv.LicProvisionID,
lv.SourceProvisionCorpCode,
lv.DateStartFmt
HAVING (lp.KindProvisionCorpCode = @KindProvisionCorpCode) 
AND (lv.SourceProvisionCorpCode = 2309453) 
AND (lv.DateStartFmt = 2187799)

OPEN Cur_F
FETCH NEXT FROM Cur_F
INTO
 @LicProvisionID,
 @Value_Year,
 @Year,
 @ObjCorpCode 

SET @RowNum = 0
WHILE @@FETCH_STATUS = 0
BEGIN
set @RowNum = @RowNum + 1

print cast(@RowNum as char(8)) + ' ' + cast( @Year as char(4))  
 + ' '+ cast(@Value_Year as char(15))
set @Year_dt =Convert(datetime, '31.12.' + cast( @Year as char(4)))

IF NOT EXISTS(SELECT LicProvisionValueID From LicProvisionValue 
Where LicProvisionID = @LicProvisionID 
AND YEAR(DateStart) =  @Year 
AND DateStartFmt = 2187801 
AND SourceProvisionCorpCode = 2309453)
BEGIN

INSERT INTO LicProvisionValue
(LicProvisionID,
ObjCorpCode,
SourceProvisionCorpCode,
DateStartFmt,
DateStart,
DateEndFmt,
DateEnd,
Value,
DynamicFlag,
AutoFlag
)
VALUES
(
 @LicProvisionID,
 @ObjCorpCode,  
 2309453, --факт
 2187801, --год
 @Year_dt,
 2187801, --год
 @Year_dt,
 @Value_Year,
 1,
 1
)
END

 FETCH NEXT FROM Cur_F 
 INTO 
 @LicProvisionID,
 @Value_Year,
 @Year,
 @ObjCorpCode 
END
CLOSE Cur_F
DEALLOCATE Cur_F
end -- конец процедуры
--

[Армянское Радио]

Владимир Коротенко, да, я предлагаю что-то вот такое. Можно заметить, что большая часть кода тут - это перечисление полей, а не логика.

Граница проходит не в "суровости" энтерпрайза, а в критичности порчи данных. Логика, сидящая в СУБД просто не позволит нарушить консистентность данных. Если же логика частично там, частично там - все держится на сознательности кожаных мешков, которые пишут код. А кожаные мешки, увы, ляпают ошибки чаще, чем это делает движок СУБД.

[Владимир Коротенко]

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

Это конечно ИМХО.

Answer 2

[xmoonlight]

"Пороговый/водопадный" спуск от уникального значения к неуникальным на каждом шаге (внутри одного или нескольких запросах) или "глоссарий".

Answer 3

[TheRonCronix]

100% есть. Например, не стоит делать джоин на стороне клиента, выбрав из одной таблицы, и потом в цикле выбирая из второй (даже если на второй таблице выборка идет по индексу). Лучше отправить один запрос РСУБД.