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

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

Ставить ли индекс у ресурса?
Я
   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 или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.