|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Valitov Leonid 2:5020/400 24 Jan 2001 17:13:43
To : All
Subject : Re: Зависимость производительности от роста БД (Microsoft SQL Server 7.
--------------------------------------------------------------------------------
7.0)
Hello Александр!!
> Хочу поделиться с вами своими сомнениями и услышать совет.
> Уже не первый раз сталкиваюсь с такой особенностью SQL Server'a 7.0
> что некоторые механизмы очень хорошо работают на больших объемах
> и заметно притормаживают (по сравнению с другими способами) на
> маленьких. И наоборот, то что изумляет своей производительностью
> на сравнительно небольшом количестве записей, начинает откровенно
> "затыкаться" при росте БД.
Вообще-то в каждом конкретном случае отдельно надо разбираться
но в общем с SQL сервером надо разговаривать SQL языком формулируя логику в
сложных select, insert, update конструкциях под которые сервер и
оптимизирован
я имею в виду не процедурный подход, а делать цикл по курсору да еще вложить
друг в друга такие циклы да запустить на базе в 300.000 записей
это как раз процедурный подход и есть уместный где нибудь в DBASE или
CLIPPER.
Синтаксис select, insert, update позволяет точно и однозначно формулировать
очень сложные вещи которые в итоге работают быстро почти безразлично на
каком объеме
Я лично переделывал процедуры в два листа делая из них лишь пару предложений
(нетривиальных конечно но довольно легко понимаемых)
с хорошим выигрышем по времени от 10 до 100 раз
>
> Теперь само сомнение:
> В ходе работ над повышением производительности, остановился я на таком вот
> коде:
>
> Declare Cur_1 cursor dynamic
> for
> select tbl_1.IDDOC, tbl_1.LineNo_, tbl_1.summa, tbl_1.Data,
> tbl_2.IDDOC, tbl_2.LineNo_, tbl_2.summa, tbl_2.Data,
> tbl_2.kind
> from
> tbl_1, tbl_2 left outer join tbl_3 on tbl_1.IDContract =
> tbl_3.IDContract
> where
> tbl_1.summa > 0 and tbl_2.summa > 0
> and tbl_1.number = tbl_2.number
> and tbl_1.IDContract = tbl_2.IDContract
> and (tbl_3.Data is not null and tbl_2.Data < tbl_3.Data1
> and tbl_3.Data1 > '01/01/1900')
> open Cur_1
> fetch Cur_1 into ...
> while @@fetch_status = 0
> begin
> [select, insert, update ...]
> fetch Cur_1 into ...
> end
> close Cur_1
> deallocate Cur_1
в данном случае можно предложить например
update qqq set www=... , eee=Cur_1.tab1_IDDOC .....
from ( select из твоего курсора ) Cur_1
where .......
в select лучше присвоить разные имена столбцам с одинаковыми именами
select tbl_1.IDDOC AS tab1_IDDOC ,..................
tbl_2.IDDOC AS tab2_IDDOC, .......................
>
> Данная конструкция очень хорошо работает при tbl_1 и tbl_2 объемом
порядка
> 5'000 строк каждая.
> А вот что будет, если вырастут у меня эти таблицы до размеров в 100'000
> строк?
> Hе произойдет ли у меня экспоненциального падения производительности при
> росте?
на самом деле аспектов очень много
-проектирование правильной структуры
-индексация
-правильная логика
-правильные селекты
.......................
в общем нам есть к чему стремиться :)
By Успехов
--- ifmail v.2.15dev5
* Origin: Gamma NNTP server Moscow Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: Зависимость производительности от роста БД (Microsoft SQL Server 7. 
