У меня доп индексы пару лет. Решение описано на софтпоинте, 100% рабочее.

softpoint : Управление индексами в 1С-SQL

vip писал(а) 16. Апреля 2008 :: 09:33:

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

ADirks писал(а) 16. Апреля 2008 :: 09:23:
с чего бы

ps
Очень бородатая тема.
Да, правда, раньше баловался этим, но не прижилось.
Сейчас как то получается обходиться без этой самодеятельности.

sadovnikov писал(а) 16. Апреля 2008 :: 11:24:

потому, что Цитата:

trad писал(а) 16. Апреля 2008 :: 11:37:

потому, что Цитата:

Нда... Неправильно я поставил вопрос... Переформулирую: как получается обходиться без этой самодеятельности?
P.S. Предчуствую ответ: "Как-то получается."

sadovnikov писал(а) 16. Апреля 2008 :: 11:42:

Именно так. А как по другому ответить? Ведь ты же понимаешь что все зависит от конкретной задачи.
Получается укладываться в штатные индексы. Либо задачи у меня не сильно жуткие, либо проектировать получается удачно. Скорее первое.

sadovnikov писал(а) 16. Апреля 2008 :: 11:55:

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

sadovnikov писал(а) 16. Апреля 2008 :: 10:07:

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

Arta писал(а) 16. Апреля 2008 :: 12:32:


Тебе проще - у тебя одна (?) база и ты сам за ней следишь. У нас другая ситуация, так что правка ХП - серьезное ограничение.

Arta писал(а) 16. Апреля 2008 :: 12:46:


Судя по всему, про сервер...

sadovnikov писал(а) 16. Апреля 2008 :: 12:58:

Ну так на сервере она одна. Долго ли ее поправить

Все же не понятно чем crdoc не катит для этой задачи.
Аргумент "Ей, бедной, и так тяжело." меня приводит только к тупиковому рассуждению что есть тяжело, а что есть легко 
В моей основной базе записей в црдоке почти в 4 раза больше чем в журне. но при использованиии црдока в запросах тяжести не ощущаю 

"Тяжело", например, делать связывание товара в табличной части документа и поля PARENTVAL в формате неопределенного значения. При условии, что в базе несколько миллионов документов.
Могу привести другой пример: поиск надо делать не только по товару. А по связке 2 полей - товар и его доп. характеристика.

trad писал(а) 16. Апреля 2008 :: 14:09:


Во накинулись
"К чему связь с ТЧ" - фильтр по количесву, сумме и т.д. Тоесть, по реквизитам ТЧ.
Если задачу сводить к "отбору документов по товару для построения реестра", то да.  _1SCRDOC для этого вполне хватит.
"аргумент "много милионов документов" - при относительно небольшом количество товаров (несколько тыс. позиций), но большом документообороте, ИМХО, селективность индекса будет низкой. И количество записей в таблице будет хорошо сказываться на производительности. (Или я уже бред несу?)

trad
Давай еще чуток усложним ситуацию... В отчет отбираем документы с использованием фильра по:
- одному виду документов
- периоду
- общему реквизиту с галкой Отбор (допустим, Фирма)
- товару
доп. ревизит ТЧ задействовать не будем.
Рисуем запрос:

Select
     ЖурналДокументов.Date_Time_IDDOC
From
    ЖурналДокументов
    Left Join докЗаявкаНаСкладТЧ докЗаявкаТЧ On Right(ЖурналДокументов.Date_Time_IDDOC, 9) = докЗаявкаТЧ.IDDOC
Where
   ЖурналДокументов.Date_Time_IDDOC > @Начдата And ЖурналДокументов.Date_Time_IDDOC < @КонДатаПлюс1
   And ЖурналДокументов.Фирма = @идФирма
   And докЗаявкаТЧ.ТОвар = @идТовар
   And ЖурналДокументов.IdDocDef = 998

Потом строим индекс:
CREATE  UNIQUE  INDEX [_DT998] ON [dbo].[DT998]([IDDOC], SP1002) ON [PRIMARY]

DT998 - документ ЗаявкаНаСклад, SP1002 - товар.

Чуток подправляем запрос:

Select
     ЖурналДокументов.Date_Time_IDDOC
From
    ЖурналДокументов
    Left Join докЗаявкаНаСкладТЧ докЗаявкаТЧ On докЗаявкаТЧ.IDDOC = Right(ЖурналДокументов.Date_Time_IDDOC, 9) And докЗаявкаТЧ.ТОвар = @идТовар
Where
   ЖурналДокументов.Date_Time_IDDOC > @Начдата And ЖурналДокументов.Date_Time_IDDOC < @КонДатаПлюс1
   And ЖурналДокументов.Фирма = @идФирма
   And ЖурналДокументов.IdDocDef = 998

И, блин, не видим никакого ускорения
Слишком мало строк приходится на связывание с докЗаявкаНаСкладТЧ.

ИМХО, использование _1SCRDOC в данном случае только снизит скорость выполнения запроса.

Цитата:

И что получается. Доп.индекс пезполезен?

Цитата:

а у тебя есть возможность проверить?
Цитата:

Честно говоря, я в некотором офигивании...
Вот запросы:

Declare @идПолныйТовар Char(23), @Начдата Char(8), @КонДатаПлюс1 Char(8), @идФирма Char(9), @идТовар Char(9)
Set @идПолныйТовар = 'B1   C     9           '
Set @идТовар = '     9   '
Set @Начдата = '20070201'
Set @КонДатаПлюс1 = '20070301'
Set @идФирма = '     3   '

Select
     cd.Child_Date_Time_IDDOC
From
     _1scrdoc cd (nolock)
     Inner Join ЖурналДокументов j (nolock) on j.IdDocDef = 998 And j.Date_Time_IDDOC = cd.Child_Date_Time_IDDOC
Where
     cd.mdid = 3555
     And cd.parentval = @идПолныйТовар
     And cd.Child_Date_Time_IDDOC > @Начдата And cd.Child_Date_Time_IDDOC < @КонДатаПлюс1
     And j.Фирма = @идФирма
--order by cd.Child_Date_Time_IDDOC



Select
     ЖурналДокументов.Date_Time_IDDOC
From 
    ЖурналДокументов
    Left Join докЗаявкаНаСкладТЧ докЗаявкаТЧ On Right(ЖурналДокументов.Date_Time_IDDOC, 9) = докЗаявкаТЧ.IDDOC
Where
   ЖурналДокументов.Date_Time_IDDOC > @Начдата And ЖурналДокументов.Date_Time_IDDOC < @КонДатаПлюс1
   And ЖурналДокументов.Фирма = @идФирма
   And докЗаявкаТЧ.ТОвар = @идТовар
   And ЖурналДокументов.IdDocDef = 998

План выполнения - во вложении...

первый план вполне нарядный  
и каков результат(вывод): отбор vs доп.индекс?

если по общему реквизиту Фирма есть отбор, то можно еще несколько оптимизировать мой запрос и избавиться от лукапа.
Select  
    cd.Child_Date_Time_IDDOC  
From  
    _1scrdoc cd (nolock)  
    Inner Join ЖурналДокументов j (nolock) on j.IdDocDef = 998 And j.Date_Time_IDDOC = cd.Child_Date_Time_IDDOC  
    Inner Join ЖурналДокументов j2 (nolock) on j2.Фирма = @идФирма And j.Date_Time_IDDOC = cd.Child_Date_Time_IDDOC  
Where  
    cd.mdid = 3555
    And cd.parentval = @идПолныйТовар  
    And cd.Child_Date_Time_IDDOC > @Начдата And cd.Child_Date_Time_IDDOC < @КонДатаПлюс1  
--order by cd.Child_Date_Time_IDDOC

trad писал(а) 17. Апреля 2008 :: 07:44:


Кстати, а куда бы он (отбор) нафиг делся-то? Иначе бы колонки не было в _1SJOURN 

sadovnikov писал(а) 17. Апреля 2008 :: 07:48:
ааа, ну да, ну да