Хранение данных.

Способ хранения данных определяется критерием, на сколько каждый элемент может быть самостоятельным независимым объектом, при этом изменение реквизитов элементов не должно приводить к потере смысла самого элемента. Если элемент соответствует данным критериям, то имеет смысл использовать объектные данные, в противном случае лучше использовать необъектные данные.

К объектным данным относятся данные справочников, документов, планов видов характеристик, планов счетов, планов видов расчета, бизнес-процессов, задач, планов обмена.

К необъектным данным относятся данные регистров сведений, регистров накопления, регистров бухгалтерии, регистров расчета, перерасчетов, последовательностей и констант.

При обращении к объекту, данные объекта считываются целиком, включая данные табличных частей. Учитывая это следует анализировать данные объекта на предмет разделения на активно используемую и неактивно используемую.

Активно используемую информацию можно хранить в реквизитах самого объекта или его табличных частей.

Неактивно используемую информацию об объекте можно хранить не в самом объекте, а посредством других информационных структур. Однако при этом придется самостоятельно заботиться о поддержании целостности изменений при модификации данных объекта. В качестве хранения неактивной информации можно использовать, например, регистр сведений или подчиненный справочник.

При выборе того или иного варианта хранения, кроме разницы между «хранением необъектных данных» и «хранением объектных данных», можно еще учесть требования к уникальности информации, накладываемые используемыми объектами системы «1С:Предприятие».

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

Для подчиненного справочника таких ограничений по уникальности нет. Если необходимо хранить информацию в виде простой таблицы, то вариант с использованием подчиненного справочника будет предпочтительнее.

Если в процессе работы у объекта будут добавляться новые характеристики/свойства, то надо использовать планы видов характеристик.

В ситуации, когда требуется с помощью специальных свойств выделить только один элемент, использование реквизитов объектов вообще является неверным. Например, введение булевого реквизита БазоваяВалюта в состав справочника Валюты нерационально, как с точки зрения хранения информации (поле будет существовать для всех элементов, хотя значение Истина с прикладной точки зрения уместно только у одного элемента), так и с точки зрения быстродействия. Для корректного разрешения подобных ситуаций уместно считать элементы, обладающие такими специальными свойствами, данными, общими для всей базы данных, и организовывать хранение информации об этом посредством констант или регистров сведений. 

Так же осторожно нужно подходить к использованию строковых реквизитов неограниченной длины. Крайне не рекомендуется использовать их для хранения информации, объем которой может быть достаточно большим или непрогнозируемым. Примером такого некорректного использования реквизита может служить сохранение в реквизите значения, получаемого функцией ЗначениеВСтрокуВнутр() (например, для таблицы значений, содержащей большое количество строк).

Не рекомендуется хранить в реквизитах активно используемых объектов картинки и образы файлов (использование полей типа ХранилищеЗначения), если заранее известно, что размер их будет велик. Для сохранения подобной информации следует использовать альтернативные методы.

Иерархия

Иерархия данных одной сущности.

В данном случае в основном используются иерархические справочники. У иерархических справочников задается вид иерархии и количество уровней иерархии. С точки зрения хранения данных количество уровней иерархии неважно, так как у иерархического справочника существует стандартный реквизит "Родитель", которые ссылается на вышестоящее значение. С увеличением количества уровней иерархии, количество реквизитов не изменяется. С точки зрения производительности, большая вложенность оказывает влияние на скорость отображения иерархических справочников и построения отчетов. В форме списка справочника, получение подчиненных элементов выполняется для каждого конкретного элемента, причем, если ветка не раскрыта, то данные по нему получены не будут. В связи с этим, для более быстрого отображения формы списка лучше использовать отображении простым списком (без отображения структуры). Для быстрого отображения иерархических списков некоторые предлагают использовать механизм СКД, но это вопрос спорный, так как динамические списки сами по себе используют механизмы СКД.

Часто бывает полезно у реквизитов справочника задать свойство "Использование" (Для элемента, Для группы), но это вопрос надо рассматривать с точки зрения технологии конкретной задачи, а не с точки зрения быстродействия.

Хранение подчиненных данных в составе объекта

Речь идет о табличных частях объектов. Табличные части предназначены для учета только необъектных сущностей. Если может потребоваться к запись табличной части, как к отдельному элементу, то лучше использовать подчиненные справочники или регистры.

С помощью использования табличных частей можно использовать многоуровневую иерархию, например у документа есть 2 табличные части, в каждой из которых есть реквизит "Номенклатура". В табличной части "Состав" указан перечень номенклатуры и цены, в табличной части "ДополнительныеТребования" указан набор требования к номенклатуре документа. При использовании такого метода получим 2-х уровневую иерархию Документ - Номенклатура - Доп. требования.

Сложностью такого метода является однозначная идентификация доп. требований к номенклатуре. Например, чтобы ограничить список доступных значений номенклатуры в табличной части ДополнительныеТребования, у колонки "Номенклатура" устанавливают свойство "РежимВыбораИзСписка" и, при переходе на страницу дополнительных требований очищают этот список и заполняют списком номенклатуры из табличной части "Состав". Может возникнуть ситуация, когда в документе будет несколько позиций с одинаковой номенклатурой. Для однозначной идентификации в табличные части добавляется реквизит УИД, который автоматически формируется при добавлении строк в табличную част "Состав". При добавлении записей в табличную часть ДополнительныеТребования, значение УИД заполняется в аналогичный реквизит табличной части ДополнительныеТребования. Значение УИД определяется по текущей строку табличной части "Состав".

Регистры сведений

Регистр сведений содержит уникальный набор данных в ресурсах для набора значений в измерениях. Если в регистре нет ни одного измерения, то в регистре будет одна запись, которая по своей сути напоминает набор констант.

В регистре сведений номер записи не входит в ключ, поэтому одинаковые значения измерений и даты одним документом писать нельзя, в отличии от регистра накоплений, у которых номер строки входит в ключ.

При проектировании проектировании регистров сведений следует учитывать следующее:

Структурный подход. Каждая запись в регистре сведений содержит информацию о том, что для данной комбинации ключевых полей установлены некоторые значения ресурсов. В том числе и в периодическом регистре сведений. То есть если запись добавляется или модифицируется, это выполняется для всех значений ресурсов.

Восприятие пользователем. При проектировании регистра важно проанализировать, как реально меняются значения данных, которые будут храниться в регистре, и выработать определенную модель отражения этих изменений в базе данных. Важно, чтобы отражение предметной области в регистре правильно воспринималось пользователем.

Время получения данных, необходимых для работы механизмов решения. Получение связанных данных из нескольких ресурсов одного регистра (одной таблицы) будет происходить в общем случае быстрее, нежели получение этих данных из нескольких регистров (нескольких таблиц).

Время записи информации в базу данных. Запись в несколько регистров сведений в общем случае будет выполняться медленнее, по сравнению с  записью одной записи с несколькими ресурсами.

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

Так же информацию про регистры сведений есть в статье Регистры сведений.

Использование составных полей

Рекомендации по использованию полей составных типов:

• использовать поля составных типов следует только тогда, когда это является оправданным с точки зрения логики функционирования конфигурации;
• не следует использовать составные типы (кроме ссылочных) для полей, по которым связываются таблицы. 
• Желательно избегать выполнения операций поиска и отбора по значениям полей составных типов (кроме ссылочных).
• Не следует определять поля составного типа (кроме ссылочных) в таблицах с потенциально очень большим количеством записей.
• Желательно избегать использования субконто и измерений регистров составных типов (кроме ссылочных).
• Индексирование по полям составных типов следует использовать только после тщательного анализа этого решения с точки зрения его необходимости и возможных потерь производительности.

Использование в составе составного поля только ссылочных значений не приводит к существенному снижению производительности. Ссылки считаются одним типом и в этом случае индекс строиться только один, включающий значения всех ссылочных типов.

https://its.1c.ru/db/metod8dev/content/1828/hdoc