Вход | Регистрация
 

Ставить ли индекс у ресурса?

Ставить ли индекс у ресурса?
Я
   lanc2233
 
23.05.19 - 10:18
Регистр сведений, в нем ресурс типа строка.
Подразумевается что будут выполянться запросы к этому регистру, с отбором по этому ресурсу или использованием ПОДОБНО
Если поставить индекс, ускорит ли это выполнение запроса?
 
 
   ДенисЧ
 
1 - 23.05.19 - 10:21
Зависит от запросов
   fisher
 
2 - 23.05.19 - 10:33
Если подразумевается, что про строковому ресурсу будет использоваться ПОДОБНО, то в консерватории уже что-то не так.
Индексы по большим строкам и отборы по ним - тоже ошибка в консерватории.
   seevkik
 
3 - 23.05.19 - 10:35
Строка в ресурсах это сильно
   exwill
 
4 - 23.05.19 - 10:38
(0) Индекс ПОДОБНО не ускоряет.
   Провинциальный 1сник
 
5 - 23.05.19 - 10:43
Кстати читал что индекс по ресурсу на самом деле означает индекс по "ресурс плюс все измерения", вот нафига это вообще сделано?
   lanc2233
 
6 - 23.05.19 - 10:44
(4) а просто отбор ускоряет?
   Провинциальный 1сник
 
7 - 23.05.19 - 10:45
(4) Ускоряет, если с начала строки поиск.
   Timon1405
 
8 - 23.05.19 - 10:46
(6) https://its.1c.ru/db/metod8dev#content:1590:hdoc
[ОРРХ | ОРНР1 +] Ресурс + Измерение1 + [Измерение2 +...]
Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем все измерения в том порядке, в котором они заданы при конфигурировании.
   Провинциальный 1сник
 
9 - 23.05.19 - 10:48
(8) А кто-нибудь может объяснить, зачем раздувать индекс комбинацией измерений, если надо всего лишь отбирать по ресурсу или реквизиту? Чем руководствовались в 1с?
   Кодер
 
10 - 23.05.19 - 10:50
Ресурс, по которому происходят отборы, называется измерение.
   vi0
 
11 - 23.05.19 - 10:51
(9) > Чем руководствовались в 1с?
"Доступно и всерьез" (с)
https://www.youtube.com/watch?v=5mFVnwHO-ec
   1Сергей
 
12 - 23.05.19 - 10:52
(10) +1
(9) Чем руководствуется 1с-ник, который делает отборы по ресурсу?
   vi0
 
13 - 23.05.19 - 10:52
(0) расскажи, что это за ресурс
   bolobol
 
14 - 23.05.19 - 10:52
(10) А Кодер-а, подобное утверждающего, называют, но не вслух
   vi0
 
15 - 23.05.19 - 10:52
(10) ответ неверный
   Timon1405
 
16 - 23.05.19 - 10:57
(9) ну вам же помимо самого ресурса нужны еще какие-то данные из этой таблицы? как думаете, где их быстрее взять из этого индекса или сходить за ними в саму таблицу?
   Провинциальный 1сник
 
17 - 23.05.19 - 11:00
(16) Это всё (получение данных непосредственно из индекса) возможно работает, если использовать один запрос. А если искать через код 1с отборами, а потом обращаться - то лишняя работа для sql-сервера и лишнее занимаемое место.
   nicxxx
 
18 - 23.05.19 - 11:23
(9) Вопрос - огонь! https://docs.microsoft.com/en-us/sql/2014-toc/sql-server-index-design-guide?view=sql-server-2014
The row locators in nonclustered index rows are either a pointer to a row or are a clustered index key for a row, as described in the following:
If the table has a clustered index, or the index is on an indexed view, the row locator is the clustered index key for the row.
Дальше продолжать?
   vi0
 
19 - 23.05.19 - 11:25
(18) продолжай
   hhhh
 
20 - 23.05.19 - 11:28
(12) например в типовом регистре Штрихкоды, измерение Штрихкод, ресурс Номенклатура. Происходит отбор по номенклатуре, чтобы вывести штрихкод в справочнике Номенклатура.
   hhhh
 
21 - 23.05.19 - 11:30
(12) ооо, в этом типовом регистре у ресурса Номенклатура стоит Индексировать.
   Кодер
 
22 - 23.05.19 - 11:36
(14) Не придирайся. Да, терминологически неверно, но мой способ не вреден базе.
(20) Тип там, надеюсь, не строка(200)?
   vi0
 
23 - 23.05.19 - 11:50
(22) > но мой способ не вреден базе.
твой способ очень ОЧЕНЬ базе, а точнее, архитектуре
   timurhv
 
24 - 23.05.19 - 11:56
(0) ускорит чтение, см (7), но замедлит запись.
   fisher
 
25 - 23.05.19 - 11:56
(9) Я забыл, как это называется правильно. Покрывающие индексы или как-то так.
Суть в том, что после применения индекса нужно еще и получить данные из соответствующих строк. А когда этих данных нет в самом индексе - это довольно дорогая операция, сильно снижающая эффективность использования индекса.
   fisher
 
26 - 23.05.19 - 12:04
(25) + По сути получается, что размер данных увеличивается во столько раз, сколько таких индексов используется (и запись замедляется). Зато каждый индекс работает почти как кластерный по эффективности.
   Eiffil123
 
27 - 23.05.19 - 12:28
(3) а где строке быть? в измерениях?
   Tonik992
 
28 - 23.05.19 - 12:42
(12) Вы слишком вошли в кураж)
такие задачи бывают
   Вася Теркин
 
29 - 23.05.19 - 12:49
(12) Это методический вопрос - что к чему привязано. В одном процессе автомобили у водителей, в других - есть ответственные за автомобиль.
А регистр будет один и не получится сделать два измерения. РС распухнет. Если  в одной машине одно водительское кресло, то измерениями будут Авто.
   Вася Теркин
 
30 - 23.05.19 - 12:50
Хотя по водилам запросов будет больше и шире
 
 
   Вася Теркин
 
31 - 23.05.19 - 12:51
ибо авто - это рабочие центры. Методически.
   Вася Теркин
 
32 - 23.05.19 - 12:52
из них потом можно группы заменяемости склепать. А с водителями так не поступишь. Текучка и ваще.
   nicxxx
 
33 - 24.05.19 - 11:10
(25) Это называется RID Lookup (для кучи) или Key Lookup (для кластерного индекса).
(19) Key lookup возможен только по всем ключам кластерного индекса, а в регистре это все измерения. Таким образом, все измерения будут присутствовать в любом некластерном индексе.
   vi0
 
34 - 25.05.19 - 04:40
(33) но ключ кластерного индекса хранится только в листьях некластерного индекса
   Сияющий в темноте
 
35 - 25.05.19 - 06:42
В случае кластерного первичного индекса ссылаться на записи нельзя,т.к.они постоянно перемещаются для создания индекса.
в случае некластерного первичного индекса записи перемещаются только при сжатии таблицы,и можно ссылаться на саму запись.
в итоге,для вторичного индекса некластерный режим гораздо производительнее.
   Конструктор1С
 
36 - 25.05.19 - 06:56
(5) потому что отбор редко бывает по одному полю, обычно по набору измерений
   Конструктор1С
 
37 - 25.05.19 - 06:58
(9) при правильном проектировании отбор всегда будет накладываться по всем измерениям, или хотя бы по их большинству
   vi0
 
38 - 25.05.19 - 07:08
(35) ты какое утверждение подтверждаешь или опровергаешь?
   Провинциальный 1сник
 
39 - 25.05.19 - 07:10
(36) То есть 1с в очередной раз не дает выбора. Жрите что дают. Хотите быстрый поиск по ресурсу и реквизиту - а вот вам хрен, получите в довесок кортеж всех измерений.
   Провинциальный 1сник
 
40 - 25.05.19 - 07:15
(39) Да и вообще, галочка "Индексировать" - семерочный атавизм. Следовало бы дополнительные индексы ввести как отдельную сущность объекта метаданных, чтобы можно было создавать произвольные индексы по произвольному сочетанию реквизитов, измерений и ресурсов - при необходимости. И чтобы это можно было делать в том числе в расширениях.
   vi0
 
41 - 25.05.19 - 07:21
(40) Какие у тебя были реальные задачи, где была такая необходимость?
   Провинциальный 1сник
 
42 - 25.05.19 - 07:33
(41) Надо вперед смотреть. У меня не было, но тут на форуме упоминались такие задачи, когда приходилось влезать в sql-сервер и создавать там индексы.
   Конструктор1С
 
43 - 25.05.19 - 10:31
(40) и без этого есть уникумы, которые врубают индексирование "про запас"
   Конструктор1С
 
44 - 25.05.19 - 14:39
(42) это всё от кривой архитектуры
   vi0
 
45 - 29.05.19 - 11:21
(34) хотя по факту размер некластерных на диске не отличается, если проиндексировать по одному полю на уровне sql


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.