Почему не рекомендуется создавать измерения регистра примитивного типа? #604263

Кто может объяснить, почему не рекомендуется создавать измерения регистра примитивного типа? Про измерения составного типа понятно - из-за особенностей хранения, индексирования и сравнения полей составного типа в СУБД, а вот с примитивным не понятно почему не рекомендуется.

А зачем?

Кем не рекомендуется?

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

Библия (не путать с религией)

Салон по продаже сотовых. Регистр остатков. Измерение IMEI - число.

имхо строковые не рекомендуются, а целочисленные и даты сойдут

строковые некошеры только с переменной длиной

ну и с регистром строк мона напортачить

да вот в мозгу сидит, а где это читал или слышал - не помню

В проф.разработки это написано. Правда сходу врятли найду

вот тоже сегодня ее просматривал - не нашел

делай если надо и примитивные и составные. С примитивными - точно не надо делать, остальное хз

некошерно делать составные типы включающие примитивные

вопрос не в том, сделать-то можно измерение примитивного типа и сам много раз так и делал, но в чем проблема с такими измерениями? Чтение запись увеличится по времени или получение итогов или еще что?

+100500

особенно если несколько таких измерений

Строки неприятно индексировать :) Почему не рекомендованы составные поля, включающие примитивные - значения каждого из 3 возможных примитивных типов хранятся в отдельных колонках, в то время как все ссылочные составные описываются 2 полями  ссылочная таблица + ИД

Кому неприятно? СУБД? Вообще то примитивных 4: строка, дата, число, булево

Совершенно верно - 4. Очепятко. Изменение базовой кодировки СУБД приведет к необходимости пересчета индекса и само собой разным результатам для разных кодировок

ещё есть Null и Неопределено

null и неопределено это же не типы данных, это служебные типы

Это касается регистров остатков. И рекомендация основана только на том, что появляются случаи, когда становится сложнее отслеживать правильность, ну т.е. если, например, сделать измерение строкой, то от простой опечатки (или неправильного написания) регистр просто не будет закрываться. Может слишком грубый пример, но он очень хорошо отражает причину такой рекомендации.

> И рекомендация основана только на том, что появляются случаи, когда становится сложнее отслеживать правильность, ну т.е. если, например, сделать измерение строкой, то от простой опечатки (или неправильного написания) регистр просто не будет закрываться жестокий бред...

очень похоже на правду, т.е. не рекомендуется из-за человеческого фактора

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

может быть вы осветите этот вопрос?

на измерение примитивного типа и в индексе и в таблице хранения выделяется только одно поле. При чем здесь длина индекса?

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

вы наверное перепутали с составным типом

порекомендуйте букварь :)

"Проф. разработка 8.0"

пока только одно разумное объяснение

Отрывки из статей ИТС: "Нагрузка на систему существенно возрастает, если используются поля, в которых совмещаются ссылочные типы и примитивные типы или несколько примитивных типов. Такие поля рекомендуется использовать только в специальных случаях.   Наиболее "опасной" является ситуация, когда поле с составным типом, включающее ссылочные поля и примитивные типы или несколько примитивных типов, участвуют в индексах. Соответственно не рекомендуется использовать такие поля в измерениях регистров и в типах субконто." "При определении структур регистров накопления и регистров бухгалтерии следует внимательно относиться к определению состава измерений и количества субконто. Так как система поддерживает хранение рассчитанных итогов по этим регистрам, то количество измерений, типы данных измерений, а также количество и типы данных субконто определяют состав ключевых полей в таблицах хранения итогов. Большая длина или большое количество ключевых полей может существенно снизить производительность работы системы."

спасибо, полезная инфа, но в ней превышено ограничение не по количеству полей индекса - 16 полей, а по размеру индекса - 900 байт. Получается что проблема только в длинне строк, т.е. если бы он сделал 12 измерений типа Строка с длиной 10, тогда бы индекс создался.

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

получается с булево и с дата вообще не может быть проблем, при использовании в измерениях. Ну теперь вроде все понятно стало. Всем спасибо

странно, сейчас создал регистр сведений с 12 измерениями типа Строка переменная 1000.(Кстати нельзя создать измерение с неограниченной длиной строки в 540 платформе) Все нормально создалось, индекс тоже в SQL создался, состоит из 12 полей, размер каждого - 2000(не знаю в чем). Может в 2008 R2 уже другие ограничения на индекс?

вот по полям ограничение прошло - создал 17 измерений, строка 1000, в индексе всего 16 полей

если-бы 1с нормально работала с примитивными типами - проблемм не было... реально примитивный тип в 1с это ИдентификаторТипа+ХарактеристикаТипа(длина,точность)+Значение. по этому булево занимает не 1 бит, и даже не 1 байт а куда больше :)

индксы создаются, ограничение есть на кластерный индекс, если разницу понимаешь - то велком, иначе - читать в поиск

В правда (особенная жесть в бух-регистрах получается). Все остальное - бред и ОБС.

Че то ты загнал.

Данными заполнил?

Примитивный тип - это именно Numeric NVarchar DataTime Binary - для булево, непонятно, есть же bit в SQL.

Вот - лучшее, что читал по индесам

во первых я имел в виду именно принцип построения индекса а не хранение данных, а во вторых глянь в табличку как там реально хранится :)

Вот как то так

да, тож это читал, хорошая статья

про какое ограничение говоришь, по количеству полей или по длине 900 байт? Хочещь сказать что для некластерного индекса нет ограничений по длине или по полям?

Мне вот всегда было интересно, по каким правилам "растут" эти деревья индексов. Фиг с ней с поддержкой сбалансированности. Что в таких деревьях динамическое - количество уровней или количество веток у узла?