Каталог решений - Приложение к публикации: Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL. (с)

В основной статье выдвигается тезис, что свёртка базы данных (БД) делается только из-за размера БД. Позволю себе не согласиться с автором.

Но, полностью соглашусь с утверждением автора основной статьи:

«В современных условиях очень странно бывает иногда слышать «нам нужно свернуть БД 1С — её объём превышает 50 ГБ».»(с)

И добавлю, что размер БД увеличивается по мере внесения в неё информации. А информация в базе данных хранится в виде таблиц содержащих записи. Т.е. очевидный вывод — чем больше записей в БД, тем больше её размер. И, естественно, можно предположить обратное. При этом у пользователя появляется «ощущение», что чем больше размер БД — тем медленнее работает система. Действительно, это не так. Производительность системы почти не зависит от общего размера БД. Производительность системы зависит от количества записей и схемы базы данных.

Схема БД продуктов «1С:Предприятие» ориентирована на решение учетных/отчетных задач (УОЗ).

Для задач такой направленности характерно:

1) Использование в качестве исходной информации бумажный (первичный) документ. Как на «входе» системы, так и на «выходе».

2) Цикличность накопления и обработки информации.

Т.е. применимы такие понятия, как: закрыть/открыть период, входящие/исходящие итоги, пересчитать итоги, архивирование «первичной» информации, итоговый (балансовый) отчет за фиксированные периоды, итоги на дату, последовательности документов (пачки) и т.д.

Т.е. в таких ИС моделируется УОЗ и вся схема базы данных «заточена», именно, на решение подобных задач. Т.е. отражается «житейское» представление человека в «кишках» информационной системы практически без изменения.

Естественно, предположить, что пользователь, общаясь с УОЗ-ориентированными информационным системами подразумевает полное исчезновение «первичной» информации после того, как, грубо говоря, сдан «балансовый отчет» и срок обязательного хранения «первичных» документов закончился.

И тут «сходятся» желания пользователя и «системного» администратора — убрать лишнюю информацию. Как в смысловом (предметном) понимании, так и в компьютерной БД. Т.е. для одного человека это — оставить только «входящие итоги», для другого — убрать лишние записи в таблицах БД. Т.е. сделать свертку БД…

Но, развитие информационных систем идет в сторону накопления и обработки наиболее полной (интегрированной) информации о деятельности людей. А полнота подразумевает как долгосрочность хранения так и отсутствие фиксированной периодичной обработки и анализа информации. Т.е. места для такого понятия как «свертка БД» — НЕТУ.

Возникает «конфликт» между концепцией (архитектурой) платформ «1С:Предприятие» (всех версий) и задачами которые на неё возлагается.

И этот «конфликт», в большей степени «подогревается» основополагающими понятиями систем «1С:Предприятие» — «монолитное» хранение в БД документов и «раскладывание» информации по регистрам с целью обобщить разнородные виды документов. Т.е. регистр можно «обозвать» общим составным индексом (в терминах СУБД) для множества иерархических структур (документов).

И всё было бы хорошо, кроме одного — таблица для хранения регистров имеет суммарное количество записей по всем видам документов «входящих» в регистр.

Но, внешне, ничего плохого нету. Ведь, пользователь редко обращается к старой информации. А, информация в регистрах лежит в хронологическом порядке. Да, сама информация — в хронологическом. Но, регистр — это таблица БД с индексом по измерениям. Допустим, что СУБД строит индекс в виде «B-дерева». Это означает, что записи регистра в индексной структуре будут представлены не в хронологическом порядке, а в «смысловой». И если система не обращается к «старым» записям таблицы регистров (и документам их порождающим) то «сталкиваться» с ключами индекса регистров от «старых» записей, ей придется.

Мне неловко приводить собственное описание способов представления и обработки «индексных структур» в СУБД, т.к. … Но, к этим описаниям имеет смысл добавить, что любые действия с деревьями требуют использования «технологических» блокировок. Как при записи, так и при чтении записей таблицы в порядке индекса. Т.е. если обрабатывается регистр в порядке индекса с ключом: «Товар+…+….», то будет приостановлена работа (условно говоря) со всеми документами, отчетами и т.д. использующими одинаковое значение «Товар». А время заблокированного состояния зависит от «глубины и ветвистости» дерева. Которое, в свою очередь, зависит от количества записей таблицы и от «характера значений» ключей. Могут возникать, условно говоря, и конфликт блокировок (deadlock).

Но, в области СУБД-строения и ЭВМ-строения с этими «проблемами» борются. Разными способами, и с переменным успехом. Но, думаю, гораздо большего успеха в этой борьбе можно добиться разработкой схемы базы данных отвечающей не только УОЗ проблематике, но и более общим задачам АСУПа.

Возвращаясь к основной статье, приведу из неё цитату:

«Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили.»(с)

Похоже на правду. Только причина не указана — почему не приходит в голову свертывать базы данных в этих системах. А причина, думаю, простая. Эти системы не ориентированы только на УОЗ в сути своей архитектуры.