При проектировании архитектуры в 1С:Предприятии 7.7 на платформе DBF программисты часто сталкиваются с дилеммой: стоит ли объединять множество данных в одну таблицу (справочник или документ), создавая "длинные" записи, или лучше распределить их по нескольким таблицам, увеличивая количество "коротких" записей. Рассмотрим этот вопрос с точки зрения производительности, сетевого трафика и внутренних ограничений движка DBF/CDX.
Проанализируем ситуацию, представленную в вопросе: что эффективнее — 1 000 000 записей по 30 байт или 33 333 записи по 900 байт? На первый взгляд может показаться, что меньшее количество записей ускорит поиск, так как системе нужно перебрать меньше элементов. Однако специфика 1С 7.7 в файловом варианте диктует свои правила. Разберем по шагам, почему "короткие" записи в большинстве случаев оказываются предпочтительнее.
Важно понимать, что 1С 7.7 работает по принципу файлового сервера. Это означает, что вся интеллектуальная работа по обработке данных выполняется на стороне клиента, а не сервера. Выясним причину, по которой длинные записи замедляют работу в сети:
Когда вы обращаетесь к реквизиту объекта (например, Спр.Наименование), движок DBF считывает из файла всю строку целиком. Если в вашей таблице 90 реквизитов по 10 символов, то при попытке прочитать всего одно поле система прокачает по сети все 900 байт. В случае коротких записей (например, 3 реквизита), объем передаваемых данных составит всего 30 байт. При массовых выборках (отчеты, переборы справочников) "длинные" записи создают колоссальный "оверхед", забивая пропускную способность локальной сети бесполезной информацией.
Рассмотрим, как операционная система Windows взаимодействует с файлами на диске. Чтение происходит не побайтово, а страницами, стандартный размер которых обычно составляет 4 КБ (4096 байт). Проанализируем ситуацию с точки зрения плотности данных в одной странице:
Вывод: Чем короче запись, тем выше вероятность, что нужные данные уже находятся в кэше процессора или оперативной памяти, что дает кратный прирост производительности.
Для разработчиков на 1С 7.7 одним из самых болезненных ограничений является лимит размера файла DBF в 2 Гигабайта. Длинные записи (например, по 900 байт) крайне неэффективно расходуют это пространство. Вы очень быстро достигнете технологического потолка, даже если количество документов в базе невелико. Разделение данных на "короткую" основную таблицу и подчиненные справочники позволяет хранить в основной таблице только жизненно важную информацию, продлевая срок эксплуатации базы данных до необходимости перехода на SQL или свертки.
Посмотрим на работу индексных файлов .cdx. Они строятся по принципу B-дерева, где данные хранятся в блоках (обычно по 1024 байта).
Рассмотрим особенности индексации:
INSERT/UPDATE) системе нужно обновить не только DBF, но и все связанные индексы. Чем больше полей в таблице, тем медленнее происходит расчет смещений и обновление индексного дерева.Хотя в 1С 7.7 реализована блокировка на уровне всей таблицы, время, на которое таблица "замирает" при записи, напрямую зависит от длины записи. Запись 900 байт с обновлением множества индексов занимает физически больше времени, чем запись 30 байт. В условиях активной работы 10-20 пользователей это приводит к геометрическому росту очереди ожидающих и к ошибкам "Объект заблокирован".
Проанализировав все технические аспекты, мы можем сформулировать следующие правила оптимизации структуры данных в DBF-версии 1С 7.7:
.cdx файла относительно .dbf, тем быстрее будет работать поиск и выборка.Таким образом, для 1С 7.7 стратегия "много коротких записей" является технически более обоснованной и производительной, чем хранение избыточных данных в одной широкой таблице.