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

Создавать реквизит, совпадающий с предопределенными - жутко плохо. Не делай так.

(1) Я прекрасно знаю, что делать так нельзя. Суть моего вопроса "Когда используется ТО, а когда ЭТО". Когда использовать подчиненность, а когда создать свой реквизит (без подчиненности)

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

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

(4) В каком случае мне выставлять подчиненность в объекте справочника метаданных, а когда можно просто создать реквизит, типо "Владелец". - вот так может проще

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

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

(4) Когда нужно использовать подчиненность - используют подчиненные. Если же подчиненность не нужна - то её не делают. Странный вопрос.

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

(9) Тоже самое можно сделать просто создав реквизит "Владелец" со ссылкой на владельца. Это точно такая же связь один ко многим. Все эти отборы автоматические тоже можно настроить. Тогда в чем принципиальное различие? В чем архитектурное обоснование использование того или другого.

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

(11) Вот пример в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так? Почему для банка и банк. счета было выбран реквизит, а для физ лица и банк. счета - подчинение?

(0) пометка/удаление подчиненных при пометке/удалении владельца

И да можно аналогично не использовать ТЧ у объектов, вместо этого создать новые "сущности" и привязать их "владельцем"
Но это изврат

(12) а разве банковский счет не подчинении физлицу? Т.е. 1с не умеет чтобы элемент был подчинении двум объектам методанных. Поэтому и банк реквизит

Особенность системы/платформы 1С в куче дополнительных "лишних" сущностей/объектов и процедур/функций
Для "упрощения" и стандартизации разработки

Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результат = процедура
Или справочники/документы тоже разница небольшая, обязательные реквизиты по умолчанию Код и Наименование vs Дата и Номер
Ну и проведение документов -  по сути которое можно вручную реализовать для справочников

(16) Справочники и документы - это наше все. Не будь этого разделения, 1С не стала бы тем, чем она стала.

(17) Это хрень если честно

Вместо разделения в Конфигураторе на всего две ветки-группы "Справочники" и "Документы"
Лучше бы сделали возможность произвольного создания своих "Групп"
И для каждого объекта метаданных выбор что это Справочник или Документ и свойства по умолчанию меняются

(18)+ * и свойства/поведение по умолчанию меняются

(18) Вот и сделай свою систему с группами. И она никому не интересна будет. А справочники и документы "зашли". Потому что помогают неопытным разработчикам делать учетные системы

(10) "Это точно такая же связь один ко многим." - да, "один ко многим", но не "точно такая же". Как я выше отметил, отличия на уровне поддержки.
(12) Опять таки всё дело в уровне поддержки. Программный уровень поддержки и/или на уровне конфигурации - более затратные методы, но они же более гибкие. Например, такая связь может быть изменена или может быть ситуативной. Что более оптимально - решают методисты. То же самый принцип подхода, имхо, что и в "константы или справочники" - постоянная информация или условно постоянная? (это риторический вопрос)

Или вот Регистры накопления изврат тоже
Почему тогда не сделали разделение на три "сущности" "Регистр остатков", "Регистр оборотов" и "Регистр остатков и оборотов"

(22)+ оно же в запросах один хрен раздельно!

(13) вот это вот очень важное отличие, что-то типо каскадного удаления.

(24) в других субд (в по сути на низком уровне в 1С) это решается ключами/триггерами

(20) Дада. Неопытным.
А потом большие системы типа ERP выглядят как будто эти неопытные их и проектировали/писали
И чтобы разобраться приходится быть дико опытным и то куча матов что к чему и зачем

Или вот почему в Конфигурторе до сих пор нет "своего фильтра по метаданным"?
По типу как отбор по подсистемам или захваченные из хранилище, но сам накидал что тебе надо в фильтр и видишь только их при установке своего фильтра!
Было бы сильно удобней при доработках

(27) Сделай подсистему "Мой фильтр" и сам накидывай в неё, что тебе надо. :)))

Garykom предлагает вернуться к макроассемблеру?
"Кац предлагает сдаться"(с)

(16) Выпилить все и оставить С+. :)

(27) В едт вроде подобные отборы есть, ну или на крайний случай плагины)

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

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

(0) Можно использовать и так и так. Лично мне больше нравится вариант без использования платформенной подчиненности. Он нагляднее. Открываешь справочник Договоры, видишь реквизит Контрагент и все сразу понятно. А с платформенным механизмом все не так очевидно

(16) "Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результа"
Оно нужно, если бы в 1с были "строгие" функции, которые не меняют вызывающий контекст. А так да. Всё можно делать функциями, без ущерба для.

+(35) И у функций есть одна удобная побочка для отладки, их можно вызывать через табло и в отладчике. А процедуру нельзя.

+(34) Да, и совсем забыл. Свой механизм гибче. Платформа допускает только одного владельца

(32) Имхо, если в конфигурации появляются справочники "Партнёры/контрагенты" и "Контрагенты/Контрагенты", то подчиненность тоже начинает зависать в воздухе. Возможно методисты со временем разродятся и появится иерархия с подчиненностью, скрестят ежа и ужа :)

(уходя) Отличная тема, пятничная.

(36) Недоделанность отладчика это отдельная вещь

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

(38) "Партнёры/контрагенты" - это вызов времени такой. когда у твоего делового партнера на вывеске ГК Крутые Пупки, а когда начинаешь писать бумаги, то там ООО "Розовый пупочек" в точке А, его филиал в точке Б, ООО "Нежный пупочек" в точке А по другой части договора, ООО "Левая Пятка" по всем точкам принимает дела по ИТ-сфере. а всё вместе - это один партнер, ты с одним CEO договариваешься обо всех аспектах.
но вот каким раком это реализовано в инфраструктуре 1с это конечно мрачно =(

(12) > в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так?

Потому что УНФ ведёт в первую очередь учёт Контрагентов, ФизЛиц и Организаций. Поэтому с точки зрения учёта важнее кому принадлежит банковский счет - какому контрагенту, физику или организации. В 99% случаев пользователя интересуют вопросы "Какие банковские счета есть у этого контрагента?" или "Чей это банковский счёт?", а не "Какие наши контрагенты имеют расчетные счета в этом банке?" или "В каком банке расчетный счет контрагента? (первичен контрагент, а не банк)".

Если бы авторы УНФ писали конфигурацию "Управление Центробанком РФ", то владельцем элемента БанковскиеСчета были бы элементы справочника Банки, а Контрагенты и ФизЛица - обычными реквизитами.

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

(20) ну делали же на клюшках систему учета на справочниках. Забавно было

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

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

(0) >Когда мне стоит делать подчиненность, а когда собственный реквизит?
Ответ очень прост. Когда подчинённый элемент абсолютно не имеет смысла без владельца, вообще ни при каких обстоятельствах - делается подчинённость. А когда он в принципе может существовать и без владельца - это всего лишь реквизит.

Я могу себе представить банковский счёт (как элемент справочника) без ссылки на справочник Банки. Например, счет в зарубежном банке, реквизиты указываются текстом, также видел счёт с названием "Наличными курьеру" :) А вот абстрактный, неизвестно чей счёт в банке - нонсенс.

Если под понятием "Реквизит "Владелец" ты понимаешь именно реквизит с именем "Владелец" - ты не сможешь добавить такой реквизит.
Равно, как нельзя создать реквизиты "Наименование", "Код" и "ПометкаУдаления"

(2) Предлагаю поставить вопрос по-другому. Когда НЕ стоит использовать подчиненность, а делать свой  реквизит?

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

P.S. Ладно, есть еще один исключительный случай. Когда ты мнишь себя архитектором 80 уровня и пытаешься изобразить на платформе 1С не учетную систему, а нечто экзотическое.

(49) Что такое учетная система по вашему?

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

(51) Кроме каскадного удаления

(50) Вопрос на монографию. :)
Это к Гению, он любит потрындеть на эту тему.

И минусом ко всему - владельцу нельзя присвоить определяемый тип

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

(55) там вообще не  было "частей" в лучшем случае - [одна] "часть", у доков. Не, конечно, решения были, но все равно лучше бы искаропки.

(55) Табличная часть это удобно. Это позволяет использовать вторичную зависимость один ко многим без явного ссылочного объекта со всеми его особенностями.

(56)+1
я уже подзабыл... действительно, 1 ТЧ у дока. корячились. да.

(57)
ну... мало что можно у справика в ТЧ.