Добрый день! Подскажите пожалуйста, чем чревато оформление регистра сведений наоборот с точки зрения логики формирования СУБД. Например, у нас есть регистр сведений, где мы храним цены на позиции номенклатуры. Но в качестве измерений выставляем цену, т.е. числовое значение, а в качестве ресурсов, наоборот, ссылку на справочник с номенклатурой? Понимаю, что надо как раз ровно наоборот делать, но допустив подобную ошибку, хотелось бы узнать, к чему она может быть привести. То есть вопрос такой: каковы могут быть последствия? Предполагаю, что они более чем есть, но формально, на этапе разработки не так очевидно, чем это может обернуться.
---
Для каждого уникального набора аргументов один набор ресурсов.

Регистр может быть непериодическим. Тогда про момент времени вообще ничего сказать нельзя.

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

Хорошо, в продолжение темы, а если есть необходимость получать цену и по номенклатуре и по цене? Не "и", а в смысле или так или так. Но чтобы обе возможности были.
---
Бред. Если цена измерение, то по значению цены 100 Вы найдёте всего одну запись регистра.

(1) Регистр в 1С очень удобно рассматривать с точки зрения математического понятия "Функция": где каждому аргументу будет соответствовать единственное значение функции.

Так вот, набор измерений - аргумент функции, набор ресурсов - значение функции, реквизиты - комментарии к записи.

Если у Вас измерения Номенклатура и Характеристика номенклатуры, то каждой паре Вы сможете назначить свою цену. Причём будут пары с одинаковой ценой.

Если Вы поменяете местами: цена - измерение, номенклатура, характеристика - ресурсы, тогда каждой цене будет соответствовать определённая пара Номенклатура/Характеристика. Т.е. с ценой в 100 рублей может быть только одна позиция.

И это не ошибка.
---
Так вот, набор измерений - аргумент функции, набор ресурсов - значение функции, реквизиты - комментарии к записи.

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

Регистр может быть непериодическим. Тогда про момент времени вообще ничего сказать нельзя.

Если он периодический: тогда в набор аргументов добавляется стандартное измерение Период типа "Дата" и появляются виртуальные таблицы СрезПервых, СрезПоследних.
---
Может быть тогда не один набор ресурсов, а набор значений ресурсов? Набор это (на сколько я понял) скорее просто перечисление, что за ресурсы мы используем. Правильно же?
---
Да, для 1С "набор значений", наверное будет точнее.

Интересно, есть какая-нибудь 1С-терминология или нет?
---
Интересно, есть какая-нибудь 1С-терминология или нет?
Думаю, здесь вполне хватит логики :)
---
Когда регистры только появились - на курсах сразу объясняли это через оси координат. "Только представьте, что их не 2-3, а такое количество, которое обеспечит вам уникальность в рамках вашей задачи".
На один набор "координат осей" может быть только "одна точка".
---
Спасибо за разъяснение... Удивляет лишь одно (оффтоп): а что, регистров когда-то не было, когда уже был 1С?!
---
Да. В 1996 году регистров еще не было.
---
вы все верно говорите, но с ценой в виде измерения можно получить несколько записей с одинаковым значением цены - придется соблюдать уникальность "вручную" и это тоже не ошибка :)
---
С одним измерением Цена вы не сможете записать две одинаковые цены 100 рублей, разным номенклатурам. Набор измерений должен быть уникальным.
---
Я начинаю понимать. То есть получается, что уникальность проверяется именно в рамках измерения. Например если мы регулярно обновляем цену. И это позволяет контроллировать, чтобы на одну и ту же позицию нельзя было по 5 раз (например) в день менять цену. А если выставим цену как измерение, то раз (например) в день не сможем эту же цену ещё чему-то назначить.
---
Если вы говорите про переодический регистр, то считайте, что вам автоматически добавляется еще одно измерение "период". Переодичность секунда, минута ....Год задается в настройках регистра. Если вы меняете цену несколько раз в день, то ставьте регистру переодичность "Секунда, минута, час". Если будет стоять переодичность "День", то последняя запись будет перетирать предыдущую(При настройках записи по умолчанию").

ну и не забывайте по важный механизм платформы СрезПоследних у переодических регистров сведений. Он выдает срез ресурсов по всем уникальным измерениям на выбранную дату
---
Проще всего объяснить это так:
Попробуйте кодом или запросом получить СрезПоследних цен по нескольким товарам.
Попробуйте сделать это с регистром сведений спроектированным как обычно, как у "белых людей" а потом тоже самое с архитектурой "наоборот".
Это называется регистр сведений "здорового человека" и регистр сведений "курильщика" =)