У меня есть поля Документ, Дата, ПризнакБулево.

Регистр сведений планируется независимый непереодический

При записи в РС уникальность записи определяется документом. Т.е. запись по полю Документ уникальна.

Запросом буду получать данные по Дате и ПризнакуБулево.

Т.е. мне нужно индексировать Дату и ПризнакБулево.

Если я сделаю Дату и ПризнакБулево ресурсами, и укажу что они индексируются. А измерение сделаю Документ и не буду его индексировать

Будет ли все это корректно работать?

Или мне нужно все 3 поля сделать измерениями, указать что они индексируются и документ поставить третьим?

Измерения:

Дата
ПризнакуБулево
Документ

Ничего индексировать не надо

Нет смысла индексировать по булевому полю
Так что периодический РС с Измерением Документ и Ресурсом ПризнакБулево

(1) Тогда теряется уникальность по полю "Документ"

(4) Да, но автор это должен обработать

(0) "При записи в РС уникальность записи определяется документом." я правильно понимаю, что в РС, будет только 1 строчка с документом и больше этот док повторяться не будет? Если так, то Док - измерение, Дата, булево - Ресурсы. Если же у вас предполагается несколько строк с документом на по разным датам - То дата будет уже измерением.

(6) Еще более правильный вопрос: дата и признак должны выдавать всегда один документ или несколько

(3) в период лучше ставить фактическую дату записи, а какую-то логическую дату в Ресурс писать.

(6) ну да, 1 документ - 1 запись. Но что на счет запроса потом к этому регистру с отбором по дате и булево. Индексации не будет как понимаю никакой.

(3) Тогда может быть ситуация когда несколько строк с одним документом появится. Мне это не нужно.

(1) А какие аргументы? К такой схеме я склоняюсь если "предположить", что измерения ТОЧНО индексируются, ну или первое измерение точно индексируется. Но можно отключить индексацию всех измерений, а поставить только у ресурсов. Тогда и уникальность записи точно будет и индексация при выборке в запросе.

(7) Дата и признак будут выдавать много документов. Документ - составной тип данных

(9) > Тогда может быть ситуация когда несколько строк с одним документом появится. Мне это не нужно.
Периодический РС

(10) Нафига если дата одна выносить ее в Измерение?
Когда можно Периодичность: В пределах дня поставить?

(11) Сегодня пришел документ с истиной, завтра пришел с ложью. Будет 2 строчки в регистре, а ТСу нужная одна.

(12) На нужную дату строчка будет одна же

(13) мне нужно будет получать данные на определенный день. Т.е. мне не нужны срезы последних, первых. Зачем мне тогда периодичность

(0) Документов сколько будет?

ИХМО, индекса по дате достаточно. Получится индекс Дата + Документ, он достаточно точный:

С сайта 1С:
Непериодический регистр сведений

Реквизит + Измерение1 + [Измерение2 +...]

Реквизиту "Реквизит" задано свойство "Индексировать".
Индекс в котором первое поле - Реквизит, затем все измерения в том порядке, в котором они заданы при конфигурировании.

Сделал 2 измерения: Документ, Сотрудник. Поставил "не индексировать"
Сделал 2 ресурса: ДатаСобытия, Выгружен. Поставил "индексировать"

Открыл обработку просмотра таблиц индексов.
В итоге 3 таблицы: Первая со всеми измерениями, вторая с ДатаСобытия в первой колонке, третья с Выгружен в первой колонке.

При такой структуре как понимаю если сделаю запрос
"Выбрать РС.Документ из РегистрСведений.МойРегистр КАК РС где РС.ДатаСобытия = &Дата и Выгружен"

То индексирование по Выгружен не будет работать

Поэтому все поместил в измерения: ДатаСобытия, Выгружен, Документ, сотрудник

Думаю так то точно будет запрос нормально работать. И нет лишних таблиц с индексами. Это если я конечно все правильно понял

(17) В консоли запросов с ИТС есть замечательная галочка "Показывать план выполнения запроса", и не нужно гадать на счет индексов. Хотя это не означает, что план всегда будет таким, при его построение оптимизатор СУБД использует много параметров, та же статистика, которая может устаревать и изменяться. В данном запросе, при первом варианте, будет использоваться индекс по дате, документ будет взят из него же, индекс для запроса покрывающий. Индекс по выгружен использоваться не будет, но как уже писали выше нет большого смысла индексировать булево - всего два возможных значения - индекс не селективный. Не забываем так же о поддержке СУБД индекса в актуальном состоянии. Во втором варианте индекс больше, при изменении данных в регистре перестроение этого индекса потребует от СУБД больших ресурсов. Я бы сделал измерение документ, все остальное в ресурсы + индекс по дате.

(17) Можешь объяснить своими словами: зачем нужен индекс по полю типа булево? Чтобы что? Чтобы отобрать одно из двух? В этой ситуации индекс ничем не поможет

"У меня есть поля Документ, Дата, ПризнакБулево."
Почему же тогда планируется непериодический и без регистратора?
Если сделать удобную (минимально необходимую) периодичность и подчинение регистратору, то можно добавить единственное измерение типа булево и все.
Типовые индексы будут:
1. По периоду и измерению
2. По регистратору
3. По измерению и периоду

Выбирайте данные и попадете в индекс.

(19) поможет

(0) сделай Документ измерением, Дату и Булево ресурсами. Индексируй Дату

Тут ещё важно, с каким отбором ты будешь запрос катать

ГДЕ ПолеДата Между &Начало и &Окончание И ПолеБулево

если с таким, то у тебя индекс отработает тупо по ПолеДата, второе поле хоть индексируй, хоть не индексируй

(21) Булево в измерении войдет в праймари ки (кластерный индекс). Поэтому индекс по булево будет не нужен.

Я бы сделал как в (1) плюс индексировать документ для обработчика событии на проверку уникальности

(23) нет

(24) Я в (21) ответил на категоричное глупое суждение про Булево

(26) да

(27) уверен?
тесты бы

(29)+ причем на разных СУБД возможно разное поведение

(29) У нас есть индексированный реквизит "ДокументОбработан", 99.9% которых обработано и нам надо выбрать необработанные документы

(22) Отбор у меня будет по дате и булево
Когда я сделал дату и булево ресурсами и проиндексировалл, а измерения не индексировал - появилось 3 таблицы индексов. Из того что я прочел следует, что отобрать по дате и булево чтобы обе колонки индексировались не выйдет, так как будет использована одна таблица индексов.

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

В общем, булево тогда сделаю ресурсом(раз нет смысла его индексировать по вашим словам), а все остальное оставлю измерениями.

Еще вариант, записи без нужного признака не писать в регистр.

(32) я бы определял структуру регистра по уникальным полям. в данном случае - если для одного документа может быть только одна дата, то документ - в измерение, все остальное - в ресурсы/реквизиты. и сколько у вас будет документов за год? если меньше 100тысяч, то можете даже не заморачиваться. эффекта от индексов не заметите.

(32) Это неправильный подход. Правильно делать как в (1). Но индексировать специально измерение с булево не нужно. Оно как-бы автоматический проиндексируется, т.к. попадет в кластерный индекс.