Добра!
Заспорили тут, да рассудит нас миста
Создается РС, у кого в одном из ресурсов может храниться  справочникСсылка или число. Я считаю, что нужно делать ресурс составного типа, мой коллега - что заводить два ресурса разных типов и сравнением числового с 0 (в запросах и вне их) понимать, где лежит реальное значение.
Погуглил, с ходу официальных рекомендаций не нашел
Мнения?
Замучу голосование, пожалуй, вдруг все окажется не проще пареной репы)

а нулл проверять не судьба?

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

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

(3) и на ваш взгляд как же быть?

ап
вяло, миста, вяло. Я не вижу ваших мнений

(5) в 1м варианте выигрываешь в использовании места и в удобстве программирования,
во 2м в скорости работы с данными

Так что вопрос из серии "Что больше - час или километр ?"

"регистр строится" под конкретную задачу.. вернее, под ситуацию.
а так - только пустотрясение пространства.

а если нужно хранить именно 0?

(0) в ресурсе хранится справочник ссылка или число - хреновый регистр. постановку задачи в студию!

(0) Объектный тип лучше примитивного, т.к. при построении индекса значение примитивного типа полностью включаеся в индекс, от чего индекс становится большим

(10) при составном типе индекс по 2-м колонкам вообще

(9) ихобретают доп.свойства, наверное

изобретают

в любом случае, физически колонок становится больше одной

(10) чем это индекс по целочисленному полю хуже индекса по UUID?

(6) не думаю, что это час или километр. все-таки это два подхода к реализации одной простой задачи. никакой катастрофы в любом случае не будет, просто интересно, какой вариант следует выбрать "по канону", так сказать

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

(8) точно не нужно

(16) вариант №3
три ресурса:
1. перечисление ТипХранимогоРесурса
2. число
3. ссылка

(6) см (14)

(14) вот мне как раз это и не нравится. Логически значение одно, если нет технических "НО", то не вижу смысла класть его в два хранилища.

(6) выигрыш в использовании места - вранье

справочник.
три реквизита - тип, ссылка, число. В РС - ссылка на этот справочник.

(21) для всех цен? круто

(19) представь, если бы ты программировал не на 1С, а на чём-то другом подключенном к SQL. Где нет составных типов

(21) а смысл? если, например, каждая запись будет уникальной

(15) Отсутствием масштабируемости. Например, нам надо завести еще один реквизит в этом "справочнике" или доп. характеристику. Колонка со ссылкой -- по прежнему одна, а колонка с доп. реквизитом идет в наш индекс.
(11) Еще лучше :)
(16) По "канону" сделать "обертку":
- легко расширять
- индекс в регистре не пухнет

(25) а то, что для каждой цены отдельный элемент справочника, причем для одинаковых цен разного товара нельзя использовать скорее всего один и тот же элемент

(16) сделай еще один тип цены "фиксированная", когда цена задается числом пиши в этот тип цен. а в РС - всегда тип цен

(21) вот это явно перебор. Особенно при записи цен

(23) хороший вопрос. Не могу придумать альтернативы дополнительному полю

(28) это логически на уровне 1С составное поле одно, на уровне СУБД их несколько

(26) Ничего страшного, разницы нет.
Гораздо хуже, если мы потом захотим добавить скидку, наценку, налог, Рекомендуемую цену, категорию покупателя и еще какую-нибудь важную информацию. Во что превратится твой регистр, особенно, если он -- один из популярных в типовой (типа "ТоварыНаСкладах")

к 30: разницы нет по сравнению с добавлением одной колонки численного типа, т.к. ссылка -- тоже число

(27) вариант хороший, но значения, стоящие за типом цен, не меняем. Либо задаем тип цены, либо абсолютную цену, чтобы потом извлечь или саму цену, или сначала тип, а затем вычислить цену.

(30) ага, ну давайте вообще откажемся в ресурсах от примитивных типов

нефиг плодить лишние сущности.
а так- творите что хотите, только не плакайте.)

(34) эм...так "два ресурса" или "нефиг плодить"?)

(35) в моем понимании лишняя сущность- составной тип.
я меряю мерой не количества :)

Я за составной. Просто потому как это более расширяемо и меньше гемора при программировании

Так

или так

т.к. информация разнородная

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

Ветке уже 2 часа.
За это время можно было сделать все и провести тестирование.
Раз 10.

(37) ну и в чем расширяемость? думаешь, если ты тип расширить решишь, то достаточно только галочку нажать?
а логику менять?

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

(44) Всё одно, что так, что этак, всё равно потом переделывать запросы, в случае чего...

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

В любом случае запрос\логику прийдется корректировать

(42) да я в принципе сложа руки не сижу. Сделал через составной тип, работаю себе дальше -)
Может еще переделаю, вас послушаю, нагрузочно потестирую, если придется

(45) только в случае с составным и выборкой через ВЫРАЗИТЬ результат все равно будет, даже если один из типов из состава ресурса убрать. Добавлять новый тип (теоретически) и того легче, запросы и запись в регистр вообще трогать не нужно будет. А если будет два ресурса, то геморроя хватит по каждому направлению

если Вы проектируете прототип программы, а не рабочее решение
то составной тип, как идеологически близкое решение
+ быстрая разработка.

если рабочее решение - то выстройте ссылочную связ иерархии
таблиц.

нужно добиться строгой типизации.

любая неодносзначность типов - зло.

(46) иногда лучше перестанет, чем будет, но окажется полная хрень

(48) Не совсем согласен. У меня РС есть где в измерении объект может быть ссылка на один из 100 справочников. Т.е. тип данных "Любой справочник ссылка".

Если идти по твоему решению, то получается ,что мне нужно 100 регистров сделать.

(49) ну решать то тебе. чего ты меня уговариваешь :)

(47) Пытаться предугадать будущие хотелки совершенно нет смысла. Жизнь она такая, постелишь соломки тут, а она сверху кирпич бросит =)
Я бы отталкивался от того однородная информация или разнородная (цена и тип цены считаю, например, разнородной).

(48) хм, а ссылочная связь иерархии таблиц всегда означает отсутствие нестрогой типизации? Если тип поля как потенциального источника связи может не являться ссылочным, нужно устранять неопределенность даже ценой расширения таблицы?

(50)
значит У Вас прототип программы.
подобная вольность  однозначо идентифицирует программу-прототип. разрабатываемую быстро и кое-как, по принципу мегагерцы все стерпят.

вобщем 1с -среда разработки прототипов.

(53)

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

и только потом кондидат на расширение с-в существующей сущности - поля таблицы.

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

(54) расскажи это всем тем, кто работает с типовыми конфами 1С. Выходит, что абсолютно все уже десяток лет работают с прототипом...бедные, как мне их жалко...и ведь даже не подозревают, работают себе и все.

(55) интересный Вы персонаж, уважаемый. Мысль строгая, речь сдержанно-образная, невнимательная грамматика и какая-то небрежная вальяжность. Нечастый Вы фрукт, посмею заметить -)
Люди интереснее 1с)
Мнение я понял, информацию принял.

(57)
с граммотностью - беда.

2 регистра с одинаковым набором измерений и у каждого свой ресурс

(59) и преимущества? Особенно по сравнению с двумя ресурсами

(56)

все уже лет 20, начиная с 1с 2.0,

работают с прототипами. бедные.

и это было нормально, пока функционал типовых конфигураций не
усложнился.

не припомню чтобы я и Вы переходили на "ты"

(0) Надо определять "по смыслу". Т.е. возможна ли ситуация (когда-нибцдь в будущем, даже если ее нет сейчас) , когда у объекта присутствуют обе характеристики одновременно -  и справочник и число...Если нет - то можно и составной тип выбрать. Если да - придется разделять сущности ибо ошибка.  Но по поводу (6) "легче программировать и  меньше места занимает" -  я бы сильно поспорил. Поэтому воздержусь.

(60) А вы прикиньте, что будет занимать меньше места на диске?