Хочу сделать несколько критериев отбора в базе. Например, "Документы по номенклатуре", "Документы по контрагенту" и т.д.
База файловая, документов много. Будут ли влиять данные критерии отбора на общую производительность?

(0)да

не влияет

(0) а проверить не предлагать?

Еще как

(4)(1) с какой стати?

критерий отбора - это дополнительный сборный индекс, сам по себе он не влияет на ОБЩУЮ ПРОИЗВОДИТЕЛЬНОСТЬ, единственное - это при записи обьекта дополнительно обновляется этот индекс и все....

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

(0)на ИТС есть(была) статья про критерии отбора

что есть крит отбора это таблица со ссылками на номенклатура/документы (к примеру)

пусть у тебя 50 тыщ элементов справочника номенклатуры и 100 типов доков. В каждом доке в среднем по 100 строк и доков по 500 в день. При записи документа заполняется критерий отбора. Через год, когда у тебя база вырастит, прикинь количество записей в этой таблице. Ага и еще индексы на это всё дело.

(6) с каких это пор размер таблицы влиет на производительность?

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

(7)+ почитай что такое денормализация данных и за чем это делают

(7)файловый вариант, размер имеет значение (с)

2(9) ну а производительность тут при чем?

(9) не имеет... компауд 1с - страничный формат имеет (как и скулевский), принцепы построения одинаковые, разница в наличие в скуле оптимизаторов

Спасибо всем, стало более понятно про критерии отбора, значит добавлю. Когда база станет большой, перепишу некоторые критерии отбора на запрос, например, "Документы по номенклатуре".

(10)(11)я не знаю что у вас за платформа но у меня скорость выполнения запроса на файловой базе к таблице с 1000 строкам и с 1 млн строками разная, таблица та же

покажи запрос

(14)ВЫБРАТЬ
   ПартииТоваровНаСкладахБухгалтерскийУчет.Регистратор
ИЗ
   РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет КАК ПартииТоваровНаСкладахБухгалтерскийУчет
ГДЕ
   ПартииТоваровНаСкладахБухгалтерскийУчет.Номенклатура В(&Номенклатура)

(4)
Недавно заметил при отборе В ГРУППЕ ИЗ СПИСКА, если указать десяток даже пустых групп то база неслабо виснет, так что смотря как отборы сделать.

1. РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет.Номенклатура - индексирован?
2. размер &Номенклатура, если более 100-500 элементов нужно переделывать на соединение по индексированому полю

(17)вопрос не в том как с оптимизировать
а это пример когда на файловой базе размер и производительность зависимые вещи

(18) 1с запросы - это как х... для дурака, стеклянный разобьет железный погнет.

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

(19)при правильном проектировании и типовые работают без блокировок и платформа не падает

а ТС советую протестировать и станет всё ясно

(20) для меня скорость вывода информации по данному критерию не важна, а так как на работу базы в целом критерии отбора мало влияют, то меня данный механизм полностью устраивает. Хотя, если база сильно вырастет, то придется переделывать на запросы.

критерии отбора планирую использовать только для быстрого отбора в меню "Перейти"