В основной статье выдвигается тезис, что свёртка базы данных (БД) делается только из-за размера БД. Позволю себе не согласиться с автором.
Но, полностью соглашусь с утверждением автора основной статьи:
"В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С - её объём превышает 50 ГБ"."(с)
И добавлю, что размер БД увеличивается по мере внесения в неё информации. А информация в базе данных хранится в виде таблиц содержащих записи. Т.е. очевидный вывод - чем больше записей в БД, тем больше её размер. И, естественно, можно предположить обратное. При этом у пользователя появляется "ощущение", что чем больше размер БД - тем медленнее работает система. Действительно, это не так. Производительность системы почти не зависит от общего размера БД. Производительность системы зависит от количества записей и схемы базы данных.
Схема БД продуктов "1С:Предприятие" ориентирована на решение учетных/отчетных задач (УОЗ).
Для задач такой направленности характерно:
1) Использование в качестве исходной информации бумажный (первичный) документ. Как на "входе" системы, так и на "выходе".
2) Цикличность накопления и обработки информации.
Т.е. применимы такие понятия, как: закрыть/открыть период, входящие/исходящие итоги, пересчитать итоги, архивирование "первичной" информации, итоговый (балансовый) отчет за фиксированные периоды, итоги на дату, последовательности документов (пачки) и т.д.
Т.е. в таких ИС моделируется УОЗ и вся схема базы данных "заточена", именно, на решение подобных задач. Т.е. отражается "житейское" представление человека в "кишках" информационной системы практически без изменения.
Естественно, предположить, что пользователь, общаясь с УОЗ-ориентированными информационным системами подразумевает полное исчезновение "первичной" информации после того, как, грубо говоря, сдан "балансовый отчет" и срок обязательного хранения "первичных" документов закончился.
И тут "сходятся" желания пользователя и "системного" администратора - убрать лишнюю информацию. Как в смысловом (предметном) понимании, так и в компьютерной БД. Т.е. для одного человека это - оставить только "входящие итоги", для другого - убрать лишние записи в таблицах БД. Т.е. сделать свертку БД...
Но, развитие информационных систем идет в сторону накопления и обработки наиболее полной (интегрированной) информации о деятельности людей. А полнота подразумевает как долгосрочность хранения так и отсутствие фиксированной периодичной обработки и анализа информации. Т.е. места для такого понятия как "свертка БД" - НЕТУ.
Возникает "конфликт" между концепцией (архитектурой) платформ "1С:Предприятие" (всех версий) и задачами которые на неё возлагается.
И этот "конфликт", в большей степени "подогревается" основополагающими понятиями систем "1С:Предприятие" - "монолитное" хранение в БД документов и "раскладывание" информации по регистрам с целью обобщить разнородные виды документов. Т.е. регистр можно "обозвать" общим составным индексом (в терминах СУБД) для множества иерархических структур (документов).
И всё было бы хорошо, кроме одного - таблица для хранения регистров имеет суммарное количество записей по всем видам документов "входящих" в регистр.
Но, внешне, ничего плохого нету. Ведь, пользователь редко обращается к старой информации. А, информация в регистрах лежит в хронологическом порядке. Да, сама информация - в хронологическом. Но, регистр - это таблица БД с индексом по измерениям. Допустим, что СУБД строит индекс в виде "B-дерева". Это означает, что записи регистра в индексной структуре будут представлены не в хронологическом порядке, а в "смысловой". И если система не обращается к "старым" записям таблицы регистров (и документам их порождающим) то "сталкиваться" с ключами индекса регистров от "старых" записей, ей придется.
Мне неловко приводить собственное описание способов представления и обработки "индексных структур" в СУБД, т.к. ... Но, к этим описаниям имеет смысл добавить, что любые действия с деревьями требуют использования "технологических" блокировок. Как при записи, так и при чтении записей таблицы в порядке индекса. Т.е. если обрабатывается регистр в порядке индекса с ключом: "Товар+...+....", то будет приостановлена работа (условно говоря) со всеми документами, отчетами и т.д. использующими одинаковое значение "Товар". А время заблокированного состояния зависит от "глубины и ветвистости" дерева. Которое, в свою очередь, зависит от количества записей таблицы и от "характера значений" ключей. Могут возникать, условно говоря, и конфликт блокировок (deadlock).
Но, в области СУБД-строения и ЭВМ-строения с этими "проблемами" борются. Разными способами, и с переменным успехом. Но, думаю, гораздо большего успеха в этой борьбе можно добиться разработкой схемы базы данных отвечающей не только УОЗ проблематике, но и более общим задачам АСУПа.
Возвращаясь к основной статье, приведу из неё цитату:
"Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили."(с)
Похоже на правду. Только причина не указана - почему не приходит в голову свертывать базы данных в этих системах. А причина, думаю, простая. Эти системы не ориентированы только на УОЗ в сути своей архитектуры.
