Проектирование
Рекомендации по проектированию эффективных структур данных¶
При определении типов полей (реквизитов, измерений и т.д.) следует внимательно относиться к созданию полей с составными типами. Поля с составными типами реально хранятся в базе данных как несколько полей. Следует учитывать, что поля с составным типом создаются системой как при явном указании составного типа, так и при выборе набора типов Характеристика, если составной тип задан в соответствующем плане видов характеристик. Чаще составные типы используются для хранения в одном поле нескольких ссылочных типов. Нагрузка на систему существенно возрастает, если используются поля, в которых совмещаются ссылочные типы и примитивные типы или несколько примитивных типов. Такие поля рекомендуется использовать только в специальных случаях.
Attention
Наиболее "опасной" является ситуация, когда поле с составным типом, включающее ссылочные поля и примитивные типы или несколько примитивных типов, участвуют в индексах. Соответственно не рекомендуется использовать такие поля в измерениях регистров и в типах субконто. Кроме того, следует по возможности избегать создания полей, в которых ссылочные типы заданы не перечислением конкретных типов, а выбором всех типов по видам объектов метаданных. Например, ДокументСсылка или ЛюбаяСсылка. Хотя количество полей от этого не возрастает, но система анализирует при работе с такими полями все типы, которые могут входить в данное поле.
Подробнее с этим вопросом можно ознакомиться в статьях:"Рекомендации по использованию в конфигурации составных типов данных", "Особенности хранения составных типов данных", "Влияние ограничений длины ключа индексов на проектирование объектов метаданных", "Индексы таблиц базы данных".
При организации хранения в информационной базе картинок, образов файлов или больших текстовых данных, рекомендуется создавать для этого отдельные структуры хранения (справочники или регистры сведений), а не включать эту информацию в состав реквизитов или табличных частей объектов, которым эта информация соответствует. Это позволит избежать считывания и записи больших объемов данных при работе с этими объектами. Подробнее с этим вопросом можно ознакомиться в статье "Хранение данных в полях типа ХранилищеЗначения".
Следует избегать хранения в информационной базе чрезмерного количества двоичных данных. Можно рекомендовать хранить в информационной базе только информацию (файлы, картинки) используемые в работе с объектами, но не хранить архивную информацию, которую не предполагается активно использовать. Подробнее с этим вопросом можно ознакомиться в статье "Хранение данных в полях типа ХранилищеЗначения".
При создании полей строковых типов следует внимательно относиться к выбору длины поля. Вся информация в 1С:Предприятии 8.0 хранится в виде UNICODE строк. Соответственно каждый символ хранится в виде двух байт. Не рекомендуется использовать строки большой длины в индексируемых полях. Например, использование длинных строк в измерениях регистров может существенно сказаться на производительности системы. Подробнее с этим вопросом можно ознакомиться в статьях:"Влияние ограничений длины ключа индексов на проектирование объектов метаданных", "Индексы таблиц базы данных".
При проектировании структур данных следует избегать ситуаций, когда одну и ту же информацию будет модифицировать значительная часть одновременно работающих пользователей. Это существенно скажется на параллельности работы пользователей и, соответственно, на общей производительности системы. Подробнее с этим вопросом можно ознакомиться в статье "Особенности проектирования конфигурации с точки зрения обеспечения параллельности работы пользователей".
При настройке свойств объектов метаданных, следует внимательно относиться к установке свойств, влияющих на создание индексов. Большое количество индексов может существенно замедлить операции записи и снизить параллельность работы пользователей. При этом следует учитывать, что индексы создаются системой не только при явном указании свойства Индексировать, но, например, и при включении поля в критерий отбора. Подробнее с этим вопросом можно ознакомиться в статьях:"Индексы таблиц базы данных", "Влияние ограничений длины ключа индексов на проектирование объектов метаданных", "Особенности использования варианта индексирования "Индексировать с доп. упорядочиванием"".
При реализации в конфигурациях задач учета наличия и движения средств следует внимательно относиться к выбору типа регистра. Для этих целей может использоваться регистр накопления и регистр бухгалтерии. Регистр бухгалтерии обладает возможностью совмещения в одном регистре нескольких учетных структур (за счет настройки субконто для каждого счета) и возможностью изменения структуры учета в режиме 1С:Предприятие. Однако регистр бухгалтерии обеспечивает меньшую производительность и параллельность работы пользователей, чем регистр накопления. Соответственно регистр бухгалтерии имеет смысл использовать только тогда, когда действительно необходимы его специфические возможности. Для решения задач по конкретным разделам учета связанных с большими объемами информации рекомендуется использовать регистр накопления. Подробнее с этим вопросом можно ознакомиться в статье "Методологические вопросы различий регистра бухгалтерии и регистров накопления".
При определении структур регистров накопления и регистров бухгалтерии следует внимательно относиться к определению состава измерений и количества субконто. Так как система поддерживает хранение рассчитанных итогов по этим регистрам, то количество измерений, типы данных измерений, а также количество и типы данных субконто определяют состав ключевых полей в таблицах хранения итогов. Большая длина или большое количество ключевых полей может существенно снизить производительность работы системы. Подробнее с этим вопросом можно ознакомиться в статьях: "Методологические вопросы различий регистра бухгалтерии и регистров накопления", "Устройство регистра накопления", "Индексы таблиц базы данных", "Влияние ограничений длины ключа индексов на проектирование объектов метаданных".
Attention
При настройке документов следует включать возможность записи движений только по тем регистрам, по которым данный документ действительно будет записывать движения. Не следует включать использование регистров «с запасом». Во-первых, тип поля "Регистратор" регистра определяется документами, в которых включена возможность записи движений по данному регистру. Кроме того, при автоматическом удалении движений выполняется удаление движений по всем регистрам, которые выбраны для данного документа. Подробнее с этим вопросом можно ознакомиться в статье "Рекомендация по связи регистров и документа для возможности создания движений по регистрам".