@kortomovmox

Господа программисты.

А кого-нибудь есть данные по следующему сабжу:
-сколько весит каждый новый документ
-сколько весит каждый элемент номенклатуры
-сколько весит каждый элемент справочника

И что составляет основной объем базы?

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

Но все же наверняка у кого-то есть приблизительные данные.

P.S. Это нужно для обоснования необходимости перехода на другую платформу для ген.директора

0

@vytfyt

Слабое обоснование - размер базы - для перехода на другую платформу...
Сколько весит один документ?
1 строка записи в таблицу 1sjournal
1 строка записи в таблицу заголовков документов
N строк в таблице табличной части документа.
А вообще настоятельно рекомендую посмотреть размеры файлов регистров: движения и остатки.
В принципе, критический размер файла ДБФ (по некоторым оценкам, которых я придерживаюсь исходя из практики) - 1 гиг.
Отсюда и отталкивайтесь. Размер таблицы движений зависит непосредственно от количества движений, а также от установленного флага "быстрая обработка движений" в регистре и "отбор движений" для измерений. В этом случае создаются дополнительные поля ключей. Размер таблицы остатков напрямую зависит от периодичности итогов. Установлено "месяц", а вам нужен большой файл для "обоснования", установите "декада" и насладитесь троекратным увеличением размера файла итогов. Еще один фактор, влияющий на размер остатков - "закрываемость" регистра: чем больше итогов, тем больше записей. Ну и, как говорится, фича 1С: при перемещении ТА (проведение документов) она записывает и нулевые итоги.
Ну и, естественно, размер обеих таблиц зависит от количества измерений и ресурсов. Реквизиты же влияют только на таблицу движений.

Вкратце, все. Кстати, не забудьте, что при пересчете итогов 1С начинает считать от "левой границы" периодичности итогов. Представляете, что происходит к концу месяца? А от этого вас не избавит никакая платформа. Разве что 1С++, которая позволяет разумно расчитывать итог: либо от левой границы периода, либо от правой.

Все. Выдыхаю, бобер.

0

@kortomovmox

Спасибо за развернутый ответ.

Но обоснование нужно в плане отказа от перехода на 8.0.
Так что меня интересует наоборот как можно меньший объем базы.

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

На 8.0 переходить очень не хочется. :(

0

@kyr

А я бы наоборот не отказывался от восьмерки. критический размер 1 гиг - это для DBF семерки. Хотя если ее коцать каждый год....
ИМХО 1С 8.1 + SQL самое оно)) хотя денег стоит немало

0

@kortomovmox

Проблема в том, что у нас от типовой ТиС осталось процентов 20, остальное писано переписано. много чего добавлено

0

@kyr

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

0

@kortomovmox

В принципе сейчас так и делает

0

@vytfyt

Рекомендую посмотреть системные требования для работы платформы 8.Х и отталкиваться от них.
Для тех, кто не понял, повторяю: 1 гиг - это не максимальный размер дбф-базы, а критический (по некоторым оценкам) размер дбф-файла. При переходе на 1С7+СКЛ выигрыша будет больше, чем 1С8+СКЛ, исходя хотя бы из того, сколько будут стоить доработка и внедрение 8.х. И стоит ли это делать, если функционал, имеющийся на сегодняшний день, вас устраивает.
Кстати, если умеете готовить Nowell, поставьте обычный файловый сервер, разместите на нем вашу базу и забудьте про "критический" размер в 1 гиг.

0

@kortomovmox

А можно поподробнее. А то я программист, а не системщик :(

0