Имя: Пароль:
1C
 
Ставить ли индекс у ресурса?
0 lanc2233
 
23.05.19
10:18
Регистр сведений, в нем ресурс типа строка.
Подразумевается что будут выполянться запросы к этому регистру, с отбором по этому ресурсу или использованием ПОДОБНО
Если поставить индекс, ускорит ли это выполнение запроса?
1 ДенисЧ
 
23.05.19
10:21
Зависит от запросов
2 fisher
 
23.05.19
10:33
Если подразумевается, что про строковому ресурсу будет использоваться ПОДОБНО, то в консерватории уже что-то не так.
Индексы по большим строкам и отборы по ним - тоже ошибка в консерватории.
3 seevkik
 
23.05.19
10:35
Строка в ресурсах это сильно
4 exwill
 
23.05.19
10:38
(0) Индекс ПОДОБНО не ускоряет.
5 Провинциальный 1сник
 
23.05.19
10:43
Кстати читал что индекс по ресурсу на самом деле означает индекс по "ресурс плюс все измерения", вот нафига это вообще сделано?
6 lanc2233
 
23.05.19
10:44
(4) а просто отбор ускоряет?
7 Провинциальный 1сник
 
23.05.19
10:45
(4) Ускоряет, если с начала строки поиск.
8 Timon1405
 
23.05.19
10:46
(6) https://its.1c.ru/db/metod8dev#content:1590:hdoc
[ОРРХ | ОРНР1 +] Ресурс + Измерение1 + [Измерение2 +...]
Ресурсу "Ресурс" задано свойство "Индексировать".
Индекс в котором первое поле - Ресурс, затем все измерения в том порядке, в котором они заданы при конфигурировании.
9 Провинциальный 1сник
 
23.05.19
10:48
(8) А кто-нибудь может объяснить, зачем раздувать индекс комбинацией измерений, если надо всего лишь отбирать по ресурсу или реквизиту? Чем руководствовались в 1с?
10 Кодер
 
23.05.19
10:50
Ресурс, по которому происходят отборы, называется измерение.
11 vi0
 
23.05.19
10:51
(9) > Чем руководствовались в 1с?
"Доступно и всерьез" (с)
https://www.youtube.com/watch?v=5mFVnwHO-ec
12 1Сергей
 
23.05.19
10:52
(10) +1
(9) Чем руководствуется 1с-ник, который делает отборы по ресурсу?
13 vi0
 
23.05.19
10:52
(0) расскажи, что это за ресурс
14 bolobol
 
23.05.19
10:52
(10) А Кодер-а, подобное утверждающего, называют, но не вслух
15 vi0
 
23.05.19
10:52
(10) ответ неверный
16 Timon1405
 
23.05.19
10:57
(9) ну вам же помимо самого ресурса нужны еще какие-то данные из этой таблицы? как думаете, где их быстрее взять из этого индекса или сходить за ними в саму таблицу?
17 Провинциальный 1сник
 
23.05.19
11:00
(16) Это всё (получение данных непосредственно из индекса) возможно работает, если использовать один запрос. А если искать через код 1с отборами, а потом обращаться - то лишняя работа для sql-сервера и лишнее занимаемое место.
18 nicxxx
 
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.
Дальше продолжать?
19 vi0
 
23.05.19
11:25
(18) продолжай
20 hhhh
 
23.05.19
11:28
(12) например в типовом регистре Штрихкоды, измерение Штрихкод, ресурс Номенклатура. Происходит отбор по номенклатуре, чтобы вывести штрихкод в справочнике Номенклатура.
21 hhhh
 
23.05.19
11:30
(12) ооо, в этом типовом регистре у ресурса Номенклатура стоит Индексировать.
22 Кодер
 
23.05.19
11:36
(14) Не придирайся. Да, терминологически неверно, но мой способ не вреден базе.
(20) Тип там, надеюсь, не строка(200)?
23 vi0
 
23.05.19
11:50
(22) > но мой способ не вреден базе.
твой способ очень ОЧЕНЬ базе, а точнее, архитектуре
24 timurhv
 
23.05.19
11:56
(0) ускорит чтение, см (7), но замедлит запись.
25 fisher
 
23.05.19
11:56
(9) Я забыл, как это называется правильно. Покрывающие индексы или как-то так.
Суть в том, что после применения индекса нужно еще и получить данные из соответствующих строк. А когда этих данных нет в самом индексе - это довольно дорогая операция, сильно снижающая эффективность использования индекса.
26 fisher
 
23.05.19
12:04
(25) + По сути получается, что размер данных увеличивается во столько раз, сколько таких индексов используется (и запись замедляется). Зато каждый индекс работает почти как кластерный по эффективности.
27 Eiffil123
 
23.05.19
12:28
(3) а где строке быть? в измерениях?
28 Tonik992
 
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
из них потом можно группы заменяемости склепать. А с водителями так не поступишь. Текучка и ваще.
33 nicxxx
 
24.05.19
11:10
(25) Это называется RID Lookup (для кучи) или Key Lookup (для кластерного индекса).
(19) Key lookup возможен только по всем ключам кластерного индекса, а в регистре это все измерения. Таким образом, все измерения будут присутствовать в любом некластерном индексе.
34 vi0
 
25.05.19
04:40
(33) но ключ кластерного индекса хранится только в листьях некластерного индекса
35 Сияющий в темноте
 
25.05.19
06:42
В случае кластерного первичного индекса ссылаться на записи нельзя,т.к.они постоянно перемещаются для создания индекса.
в случае некластерного первичного индекса записи перемещаются только при сжатии таблицы,и можно ссылаться на саму запись.
в итоге,для вторичного индекса некластерный режим гораздо производительнее.
36 Конструктор1С
 
25.05.19
06:56
(5) потому что отбор редко бывает по одному полю, обычно по набору измерений
37 Конструктор1С
 
25.05.19
06:58
(9) при правильном проектировании отбор всегда будет накладываться по всем измерениям, или хотя бы по их большинству
38 vi0
 
25.05.19
07:08
(35) ты какое утверждение подтверждаешь или опровергаешь?
39 Провинциальный 1сник
 
25.05.19
07:10
(36) То есть 1с в очередной раз не дает выбора. Жрите что дают. Хотите быстрый поиск по ресурсу и реквизиту - а вот вам хрен, получите в довесок кортеж всех измерений.
40 Провинциальный 1сник
 
25.05.19
07:15
(39) Да и вообще, галочка "Индексировать" - семерочный атавизм. Следовало бы дополнительные индексы ввести как отдельную сущность объекта метаданных, чтобы можно было создавать произвольные индексы по произвольному сочетанию реквизитов, измерений и ресурсов - при необходимости. И чтобы это можно было делать в том числе в расширениях.
41 vi0
 
25.05.19
07:21
(40) Какие у тебя были реальные задачи, где была такая необходимость?
42 Провинциальный 1сник
 
25.05.19
07:33
(41) Надо вперед смотреть. У меня не было, но тут на форуме упоминались такие задачи, когда приходилось влезать в sql-сервер и создавать там индексы.
43 Конструктор1С
 
25.05.19
10:31
(40) и без этого есть уникумы, которые врубают индексирование "про запас"
44 Конструктор1С
 
25.05.19
14:39
(42) это всё от кривой архитектуры
45 vi0
 
29.05.19
11:21
(34) хотя по факту размер некластерных на диске не отличается, если проиндексировать по одному полю на уровне sql
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство. Фредерик Брукс-младший