Переключение на Главную Страницу Страницы: [1] 2 3 4 ОтправитьПечать
Очень популярная тема (более 25 ответов) часть 5 1с sql  таблицы rg изнутри (число прочтений - 14341 )
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
часть 5 1с sql  таблицы rg изнутри
26. Ноября 2008 :: 07:48
Печать  
Ломаю голову не могу понять
Зачем для таблиц rg...
сделан класторный индекс
Период,Измерение_1,Измерение_2,...,Измерение_N

Ведь эти таблицы Очень часто и сильно меняются.
Даже если у Вас месяц ТА совпадает с текущим то все равно
все время идет физическое перестроение этих таблиц и на этом
теряется очень много времени.
Далее существенный выигрыш от кластерного индекса
мы получим только если будем обходить rg таблицу строго в порядке
период,измерение_1,измерение_2,...., измерение_n
а ведь это далеко не всегда соответсвует действительности.

Может кто скажет в чем я прав а в чем ошибаюсь в этих рассуждениях.
  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #1 - 26. Ноября 2008 :: 07:57
Печать  
Z1 писал(а) 26. Ноября 2008 :: 07:48:
Ломаю голову не могу понять
Зачем для таблиц rg...
сделан класторный индекс
Период,Измерение_1,Измерение_2,...,Измерение_N

Ведь эти таблицы Очень часто и сильно меняются.
Даже если у Вас месяц ТА совпадает с текущим то все равно
все время идет физическое перестроение этих таблиц и на этом
теряется очень много времени.
Далее существенный выигрыш от кластерного индекса
мы получим только если будем обходить rg таблицу строго в порядке
период,измерение_1,измерение_2,...., измерение_n
а ведь это далеко не всегда соответсвует действительности.

Может кто скажет в чем я прав а в чем ошибаюсь в этих рассуждениях.


Ну сказал!
Да это основной индекс для проведения в реальном режиме! Самый разумный.
Например регистр остатков - Задано Период,Фирма,Номенклатура,Склад.
Селективность - 1 к 10 в n степени.
Если где неудачно(видимо нетиповые) - вручную поправляешь порядок следования измерений.
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #2 - 26. Ноября 2008 :: 08:05
Печать  
kiruha писал(а) 26. Ноября 2008 :: 07:57:
Z1 писал(а) 26. Ноября 2008 :: 07:48:
Ломаю голову не могу понять
Зачем для таблиц rg...
сделан класторный индекс
Период,Измерение_1,Измерение_2,...,Измерение_N

Ведь эти таблицы Очень часто и сильно меняются.
Даже если у Вас месяц ТА совпадает с текущим то все равно
все время идет физическое перестроение этих таблиц и на этом
теряется очень много времени.
Далее существенный выигрыш от кластерного индекса
мы получим только если будем обходить rg таблицу строго в порядке
период,измерение_1,измерение_2,...., измерение_n
а ведь это далеко не всегда соответсвует действительности.

Может кто скажет в чем я прав а в чем ошибаюсь в этих рассуждениях.


Ну сказал!
Да это основной индекс для проведения в реальном режиме! Самый разумный.
Например регистр остатков - Задано Период,Фирма,Номенклатура,Склад.
Селективность - 1 к 10 в n степени.
Если где неудачно(видимо нетиповые) - вручную поправляешь порядок следования измерений.

Разве ту же селективность не будет обеспечивать уникальный индекс ?
А что будет с попаданием в индекс для регистра при запросе на ТА ?

Группировка Склад
Группировка Номенклатура
  
Наверх
 
IP записан
 
trad
1c++ power user
1c++ donor
1c++ moderator
Отсутствует



Сообщений: 3050
Местоположение: Киров
Зарегистрирован: 23. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #3 - 26. Ноября 2008 :: 08:18
Печать  
а какой бы ты сделал кластерный индекс для этой таблицы?
и делал ли бы его вообще?
  

1&&2&&3
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #4 - 26. Ноября 2008 :: 08:22
Печать  
trad писал(а) 26. Ноября 2008 :: 08:18:
а какой бы ты сделал кластерный индекс для этой таблицы?
и делал ли бы его вообще?

Я не делал я думаю почему так сделано.
Какие от этого плюсы и минусы.

Ну и у меня очень много мыслей как сделать.
я за ними не совсем поспеваю.
Чтобы разобраться лучше как есть сейчас  - вот и спаршиваю.
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #5 - 26. Ноября 2008 :: 08:49
Печать  
Кстати когда востанавливаем последовательность из глубокого
прошлого вот эти таблицы rg круто "кобасятся".
Т.е. если оставлять индекс как есть то во время
монопольного восстановления гораздо быстрее ( с меньшей нагрузкой на sql) сделать так
предположим что перепроводим данные с 01.02.2008
1. удаляем все записи в rg c 01.02.2008
2. во время проведения НИЧЕГО не пишем в rg.
3. после проведения по ra востанавливаем rg для каждого
периода
01.02.2008 01.03.2008  ...  01.11.2008
  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #6 - 26. Ноября 2008 :: 09:33
Печать  
Z1 писал(а) 26. Ноября 2008 :: 08:05:
Разве ту же селективность не будет обеспечивать уникальный индекс ?
А что будет с попаданием в индекс для регистра при запросе на ТА ?

Группировка Склад
Группировка Номенклатура

1. Порядок группировок не имеет значения
2. Группирование достаточно низкозатратная операция . Может имелся ввиду отбор?
3. Если имелся ввиду "отбор" по  измерениям Склад, Номенклатура, то т.к.
Справочник Фирм маленький (как правило), то появляется реальная возможность задействовать индекс с попаданием в поля
Период,Фирма,Номенклатура,Склад - очень высокая селективность.

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

А при полном перепроведении - только добавляются записи в конец таблицы - быстрее трудно придумать
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #7 - 26. Ноября 2008 :: 09:43
Печать  
kiruha писал(а) 26. Ноября 2008 :: 09:33:
Z1 писал(а) 26. Ноября 2008 :: 08:05:
Разве ту же селективность не будет обеспечивать уникальный индекс ?
А что будет с попаданием в индекс для регистра при запросе на ТА ?

Группировка Склад
Группировка Номенклатура

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

Да но при этом записи в которые в следущем периоде все время сдвигаются вниз.
Далее смотри в одном периоде предположим что товары упорядочены и индексе по алфавиту
сначала накладная с товаром Швелер скажем 02.11
записали ее в тек период
далее накладная 03.11 накладная с товаром Арматура
чтобы записать этот результат в тек период ( если его там нет)
надо сдвинуть вниз Швелер.
А если точно также не попадет фирма то нам надо будет сдвинуть очень большой кусок данных

Насчет пунктов 1-3 буду думать.


  
Наверх
 
IP записан
 
berezdetsky
1c++ power user
Отсутствует


barba non facit sisadminum

Сообщений: 1986
Местоположение: Москва
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #8 - 26. Ноября 2008 :: 10:03
Печать  
Ты правда думаешь, что при изменении кластерного индекса записи перемещаются?  Ужас
  

пароль как коньяк, чем больше звездочек, тем лучше
Наверх
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #9 - 26. Ноября 2008 :: 10:09
Печать  
berezdetsky писал(а) 26. Ноября 2008 :: 10:03:
Ты правда думаешь, что при изменении кластерного индекса записи перемещаются?  Ужас

вообще то да. я только учусь
Даже если они (данные ) и не перемещаются а перемещаются только индексы
то для таблиц rg... размер индекса почти совпадает с размером данных а значит если перемещается только индекс то это
почти одно и тоже что и сказанное все выше.
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #10 - 26. Ноября 2008 :: 10:31
Печать  
Цитата:
Если первичный ключ таблицы является последовательным, сделайте его
некласторным первичным ключом. Кластерный индекс по монотонно возрастающему
ключу менее оптимален, поскольку вы, скорее всего, не будете осуществлять
запросы   на выборку диапозона ключей в ORDER BY.
Последовательный кластерный первичный ключ может привести к тому,
что пользователи будут претендовать на одну и ту же область в базе
данных при добавлении записей,  тем самым создавая горячую точку ( hotspot )
Кен Хендерсон
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re:
Ответ #11 - 26. Ноября 2008 :: 10:55
Печать  
Цитата:

Может быть, но для восстановления последовательности в монопольном режиме нам не нужны вообще никакие блокировки.

что то интернет сбойнул
пост berezdetsky пропал и его цитата тоже

  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #12 - 26. Ноября 2008 :: 11:13
Печать  
Кстати, если уж об индексах регистров :

если в rg разработчики очень хорошо продумали индекс,
то в RA (таблица движений) - как будто индекс делал другой человек.

Кажется - возьми да повтори структуру как в rg.
Нет - лепят Цитата:
IDDOC,LINENO_,ACTNO
Кому нужен LINENO_,ACTNO ?
А чтобы провести задним числом приходится все таблицу считывать, да еще и большую часть журнала.
Лечится штатно установкой отбора движений, но в этом случае в отличии от rg -
попадание максимум в 2 поля.

Отсюда тормоза при проведении задним числом.
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #13 - 26. Ноября 2008 :: 11:21
Печать  
kiruha писал(а) 26. Ноября 2008 :: 11:13:
Кстати, если уж об индексах регистров :

если в rg разработчики очень хорошо продумали индекс,
то в RA (таблица движений) - как будто индекс делал другой человек.

Кажется - возьми да повтори структуру как в rg.
Нет - лепят Цитата:
IDDOC,LINENO_,ACTNO
Кому нужен LINENO_,ACTNO ?
А чтобы провести задним числом приходится все таблицу считывать, да еще и большую часть журнала.
Лечится штатно установкой отбора движений, но в этом случае в отличии от rg -
попадание максимум в 2 поля.

Отсюда тормоза при проведении задним числом.

не понял пересчитываются как раз rg а не ra
Индекс LINENO_,ACTNO нужен для

Регистр. ... .ПривязыватьСтроку(НомерСтроки);

а зачен нужен ПривязыватьСтроку не знаю.
наверное иак исторически сложилось
а потом оставили все как есть.

этот индекс помогает если у Вас слетел флаг rf
( тоглько аппаратный сбой ) а движения остались нельзя провести документ не разобравшись - дубль ключей возникает
так что вроде как нужен.
  
Наверх
 
IP записан
 
Z1
God Member
*****
Отсутствует


I Love YaBB 2!

Сообщений: 2906
Местоположение: Москва
Зарегистрирован: 26. Мая 2006
Пол: Мужской
Re: часть 5 1с sql  таблицы rg изнутри
Ответ #14 - 26. Ноября 2008 :: 11:31
Печать  
А по моему наоборот для RA очень хороший индекс так как
IDDOC единственен и селективность самая хорошая супер.

и ситуация следущая при любой реализации в ra может писать
только один кто "владеет" документом,
а в rg  стучаться все даже если у Вас период один = месяц ТА
и при этом нехило колбасят либо саму rg либо ее кластерный индекс.
  
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: [1] 2 3 4
ОтправитьПечать