Искать
13.07.2026
Электронный документооборот в стоматологии: почему клиники переходят на цифровые документы



04.06.2026
Новое в 1С:Салон красоты в версии 3.0.49.1



04.06.2026
Нижегородская область создала цифровую экосистему спорта на базе 1С:Фитнес клуб



28.04.2026
Новые возможности 1С:Медицина. Стоматологическая клиника в версии 2.1.33.1



24.04.2026
1С:Фитнес клуб — победитель Russian Fitness Awards третий год подряд



ГлавнаяИнформацияСтатьиЧто может привести к необходимости свертки базы?

Главная

Что может привести к необходимости свертки базы?

    Обычно с ростом объема базы данных падения производительности при оперативной работе быть не должно. Но если такое падение наблюдается, то это - признак неоптимальной работы запросов. Если производительность оперативной работы в системе зависит от количества записей, в какой либо из таблиц, то это – ошибка проектирования или кодирования системы. Эта ошибка должна быть устранена. Лечить симптом путем свертки базы, оставив без внимания саму проблему кажется нам совершенно неправильным. В этом случае следует оптимизировать запросы и исправлять ошибки проектирования, а не разбивать одну базу на несколько.
    Однако, существует ряд случаев когда необходимо сворачивать базу.
  1. рост объема информационной базы может сказаться на времени выполнения регламентных операций, таких как обновление статистик, бэкап и т.п. Если время выполнения регламентных операций становится неприемлемым, то следует разбивать базу.
  2. Еще одной причиной для разбиения одной базы на несколько может быть недостаток дискового пространства. Иначе говоря, критерием для разбиения одной базы на несколько является не объем базы (тут никаких ограничений нет), а требования бизнес-процессов конкретного внедрения.
  3. Как только начинает не устраивать производительность и после анализа ситуации видно, что дело нельзя решить другими изместными способами.
  4. Как только база вырастает до объемов, препятствующих удобному резервному копированию, реиндексации, обновлению конфигурации и пр. 
     Без быстрой дисковой подсистемы старайтесь, чтобы хотя бы половина объема базы умещалась в оперативной памяти, ибо если индексы таблицы бухитогов например в памяти не умещаются и начинают в подкачку с диска, то производительность падает как раз из-за размера базы, даже точнее некоторых больших ее таблиц. Для базы размеров 30 Gb рекомендуется RAM 16Gb и более.

Copyright © 2006 «Helix-Group»