Если обращаться запросом к Справочнику или Регистру сведений,
то к регистру будет обращение выполняться быстрее при прочих равных условиях?
(т.к. справочник хранит дополнительные служебные поля)

Вопрос что быстрее?

Спасибо.

Проверь, расскажи нам)

(0) при прочих равных по первым двум реквизитам в справочнике поискать по индексу не сможете, в а регистре сможете.

в регистре тоже есть ключ только доступа к нему нет

(2) По какому индексу?
Если я поставлю в свойствах реквизита Индексировать,
то в запросе будет использоваться индекс.

(4) по 2-м реквизитам сразу?)

(2),(5) - да, согласен. Хорошее отличие.

(0) быстрее будет справочник без кода и наименования :)

(0) в общем случае скорость одинаковая
а чтобы понять твой конкретный случай - покажи запрос

А что, автору без разницы, будет ли ссылочная целостность или не будет?

(9) Да, в данном случае ссылок не хранится. Без разницы.

в случае автора - монопенисуально

При прочих равных условиях с чего бы данные одной таблицы будут читаться быстрее данных другой таблицы?

если не нужен ссылочный тип регистр конечно.

2(9) ссылочная  целостность это слегка миф.
а вот чтобы добиться ее подобия в РС - можно завести реквизит(или даже измерение) с типом УИД

и будет полная иммитация ссылочная типа.

1С ники свойства объекта из регистра перевели в ТЧ справочника - это ж не спроста.

(16) таки ви думаете справочник быстрее регистра, поэтому?

(17) таки я думаю, что к регистру сведений неудобно ТЧ колхозить.

Тестирование на 2М записей покарало примерно одинаковые результаты.
Регистр чуть лучше, но не всегда.

В целом для данной задачи значения не имеет и больше зависит как будет обновляться/пополняться/удаляться таблица.

Скорее всего остановлюсь на регистре, хотя справочник тоже работает быстро.

Спасибо всем за советы.

(19) не хочу вас расстраивать, но в общем случае скорость выборки данных не определяется видом объекта метаданных.

Может быть вы слышали про индексы?

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

(20) расскажите нам, как поискать в справочнике по его двум реквизитам(сразу) и попасть в индекс

(22) Букварь на ночь не почитать?

(23) какой у справочника аналог индекса ByDims?

(16) в табличную часть перевели только то, на что должны распространяться те же права, что и на справочник
остальные остались в регистре

(24) в чем проблема индексировать реквизиты? мы начинаем рассуждать по каким индексам выборка быстрее? или донести до автора что постановка вопроса не корректна?

(26) в том, что составного индекса в справочнике по 2м реквизитам вы никогда не получите. постановка вопроса была "при прочих равных"

(15) Контроля при удалении не будет. То, что из РС записи могут пропадать одним нашатием кливиши, для бизнеса ахтунг

(20) Да, конечно. Индексы построены.
Но не только ими определяется выбор.

(28) можно при записи добавлять в ДополнительныеСвойства набора свой флаг, и если его нет, не давать удалять. тогда никаким полными правами без флага ни программно ни интерактивно не удалить.

(27) а что, есть факт что составной индекс работает быстрее двух раздельных?

(31) да. составной точно работает быстрее двух раздельных если запрос идет по тем же полям, что и индекс.

(31) 2 раздельных индекса <> 1 составному.
индекс может использоваться только 1

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

(33) спасибо, я в курсе.

(32) а если запрос содержит поиск в диапазоне? between например?

слово точно можно убрать из вашего предложения. заменив на - иногда.

(30) Неудобно определять, а когда же все-таки такой флаг нужно поставить - по ссылкам-то не поищешь...

(36) 2 between на 2х полях отработают быстрее, чем 2 по двум индексам.