Примерно так:
Моё мнение:
для хранения типа Число(10,2) нужно использовать определенное число байтов
для хранения ссылки ещё число байтов
И если мы делаем составной тип, то там будет примерно так: пару байт для типа, остальное для ссылки, а если простые добавляем, то ещё байты навешываем
Мнение ИТС:
http://its.1c.ru/db/metod81#content:1828:1 Простые типы отображаются так:
Тип данных Суффикс Тип поля базы данных
MS SQL Server PostgreSQL IBM DB2
Число: длина n, точность k. нет NUMERIC(n, k) numeric(n, k) dec(n, k)
Строка фиксированной длины: длина n. нет NCHAR(n) mchar(n) graphic(n)
Строка переменной длины: длина n. нет NVARCHAR(n) mvarchar(n) vargraphic(n)
Строка неограниченной длины. нет NTEXT mvarchar dbclob
Дата нет DATETIME timestamp timestamp
Булево нет BINARY(1) boolean char(1) for bit data
Хранилище значения нет IMAGE bytea blob
Ссылка на объекты базы данных одного типа RRef BINARY(16) bytea char(16) for bit data
Наряду с простыми типами могут использоваться и составные типы.
Тип поля считается составным, если
а) была включена галка составной тип
б) выбран тип Характеристика или "собирательный" тип ДокументСсылка, ПеречислениеСсылка ... ЛюбаяСсылка;
Данные составного типа представляются в базе данных несколькими полями.
Количество и состав полей базы данных определяется выбранной для данного объекта метаданных комбинацией типов. (есть ещё информация более детальная на ИТС, не буду приводить).
Так вот , если
а) Выбран один тип, в том числе ссылка на объекты базы данных одного типа.
Тогда будет отображаться это на одно поле
б) Выбрана ссылка на объекты базы данных двух и более типов. Например:
1) СправочникСсылка;
2) СправочникСсылка.Организации, СправочникСсылка.Контрагенты;
3) ЛюбаяСсылка.
Тогда будет: три поля
в) Выбраны несколько типов, отличных от ссылок, или ссылки с хотя бы одним типом, отличным от ссылок.
Например:
1) Число, строка;
2) Булево, СправочникСсылка.Контрагенты;
3) Число, СправочникСсылка.
Тогда будет: Несколько полей
Варианты перечислены в порядке возрастания ресурсоемкости. Наименее эффективным с точки зрения производительности является последний вариант. Поэтому при его использовании необходимо убедиться, что возможное снижение эффективности существенно не скажется на функционировании конфигурации.
Дополнительные проблемы с производительностью могут возникнуть, если поле, представляемое в СУБД в соответствии с последним вариантом, участвует в индексах (см. "Построение индексов").