Что влияет на объем базы и скорость работы с ней #644437

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

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

но велик ли Amedis? я не знаю...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответьте еще на и , please

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

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

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

С чего он уменьшится, если в остатках по месяцам будут храниться не схлопнутые остатки. Вот их и чисти. Если надо. Но может оно и не влияет на скорость.

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

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

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

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

ключевая проблема  производительности 1с и субд -индексы и смешанный тип бд ( oltp,  olap) в типовых конфигурациях что затрудняет использование индексов. отношение объёма индексов к данным oltp 1:1 olap 10:1 но даже если  разнести контуры в бд 1с не поддерживает произвольные составные индексы тк  для традиционных субд скорость записи  к чтению отличается в 20-100 раз ---------------------- 1) Добавление одного измерения к регистру (как минимум поля в кластерный индекс) пропорционально добавляемому размеру данных уменьшает скорость записи. а вот скорость  чтения из разных контуров (oltp,olap) может сильно изменяться в зависимости от задач. от того как полияет порядок измерения на селективность запросов (те без глобальных переделок измерение нужно добавлять последним) поэтому нужно подходить осмысленно: при проектировании расчитвать колво чтений записи для регистров oltp. 2) - Добавление одного ресурса к регистру пропорционально добавляемому размеру данных уменьшает скорость записи.