В свете доработок УПП и Комплексных появилась потребность узнать: что  больше, что меньше, что никак не влияет на объем базы и скорость работы с ней.

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

Буду рад как развернутым ответам, так и отсылкам к трудам великих программистов.

http://infostart.ru/public/128362/
но велик ли Amedis? я не знаю...

(0) Всё вышеперечисленное

(3) А как насчет больше меньше

(4) Многое индивидуально. Определяется эмпирически. Зависит и от структуре наполнения данных.

(3) +1,

(4) а тут уже куча нюансов) например измерение в регистр сведений - тип, индексируется ли и т.д. и т.п.; тип регистра сведений ... если стоит такая жизненно важная потребность - сходите на курсы 1с эксперт по технологическим вопросам, направятв  нужном направлении)))

(0) для УПП архитектура Рг пофиг,
скорость работы измениться на промиле

Незакрытые остатки в регистре накопления "Остатки и обороты" - когда много записей(более 100 тыров в день)  очень влияют

Незакрытые остатки - радикально влияет. В любом случае это зло.
Добавление измерения - существенно влияет. Конкретное влияние может изменяться  от мизерного до крайне важного, т.к. может привести к незакрытию остатков.
Добавление ресурса - не влияет, если ресурс опять же не образовывает незакрытых остатков.
Добавление нового регистра - зависит от характера использования. В абсолютном большинстве случаев - вообще не влияет.

По объему:
Добавление ресурса в меньшей,
Добавление измерения в большей,
Добавление регистра, все зависит от наполняемости и типов измерений.

По незакрытыми остаткам написали уже.

Влияние объема базы на скорость работы зависит от настроек СУБД и мелкая база по объему может тормозить. А может и большая база раздутая за счет индексирования, но работать шустро, здесь всегда надо искать компромисс.

запрос в цикле усмирит вашу летающую как птичка базу до уровня улитки.

(11) Выборка в цикле вместо запроса - вот это сила!!! :):):)

обьем и скорость тесно связаны...

при правильном подходе:
чем больше обьем - тем больше скорость (например индексирование поля добавляет обьем и увеличивает скорость)

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

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

(8) Мне досталась база по наследству. В регистр "Заказы поставщикам" предопределенный добавили пару измерений. Поправили "приход", а "расход" забыли. В итоге куча остатков вроде +1 -1. Вопрос: если я закрою эти остатки сегодняшним числом, могу ли рассчитывать на то, что регистр уменьшится? Или только на то, что в будущем он будет не так сильно расти?

(12) ты хочешь сказать, что объектная модель шустрее чем табличная? То есть если я буду делать не запросом перебор, а командами, то это будет быстрее?

(0) Я еще жду ответы на (14) и (15), но уже сейчас спасибо за ответы, не так часто дельные ответы получать приходится чаще всяких отписок

(2) Благодаря это й обработке увидел, что 80% моей базы занимают электронная почта и вложения.....

Ответьте еще на (14) и (15), please

(18) о_О Ненене, в (12), исходя из (11), я имел ввиду, что это, не то что в улитку превратит БД, а вообще ее остановит.

Очень хочется узнать ответы на (14) и (15)

(14) Не уменьшится, если ты сделаешь это текущим числом. Просто меньше будет расти.
(15) Нет. Это была издёвка

(14) С чего он уменьшится, если в остатках по месяцам будут храниться не схлопнутые остатки.

(17) Вот их и чисти. Если надо. Но может оно и не влияет на скорость.

смешались кони и люди (с) в (0)

(0) Ну спасибо, очень помогло. Ясно, что если что-то будет долго проводится или формироваться, есть смысл посмотреть из-за чего, и принимать меры. Стандартного решения нет.

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

(24) "Ясно, что если что-то будет долго проводится или формироваться, есть смысл посмотреть из-за чего, и принимать меры." - замечательный вывод.

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

-индексы

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

отношение объёма индексов к данным

oltp 1:1
olap 10:1

но даже если  разнести контуры в бд

1с не поддерживает произвольные составные индексы


тк  для традиционных субд

скорость записи  к чтению отличается в 20-100 раз

----------------------
1)
Добавление одного измерения к регистру

(как минимум поля в кластерный индекс)

пропорционально добавляемому размеру данных уменьшает скорость записи.

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

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

поэтому нужно подходить осмысленно: при проектировании расчитвать колво чтений записи для регистров oltp.


2)
- Добавление одного ресурса к регистру

пропорционально добавляемому размеру данных уменьшает скорость записи.