|
Отличие созданного реквизита "Владелец" от свойства подчиненности справочников | ☑ | ||
---|---|---|---|---|
0
FrostBite101
21.02.23
✎
08:17
|
Добрый день, хотел уточнить по поводу свойства подчиненности у справочников. Есть ли какая-то принципиальная разница между создания своего реквизита "Владелец" и выставления подчиненности одного справочника другому. В обоих вариантах у нас есть реквизит, который указывает на владельца, созданный мной реквизит можно сделать обязательным и тогда отличий вообще не будет в план архитектуры. Да, при указании подчиненности открывается возможность использовать команды форма для перехода, а также создаются доп. индексы. Но команду для перехода можно "имитировать", динам. список с отбором. Также можно проиндексировать созданный реквизит "Владелец" и тогда даже одно индексное поле будет аналогична той, где используется подчиненность. Я понимаю, что при использовании подчиненности добавляется куда больше полей инд. полей. Так в чем в общем то вопрос... Когда мне стоит делать подчиненность, а когда собственный реквизит? В типовых конфигурациях чаще всего создается реквизит, а подчиненность используется куда реже.
|
|||
1
Chai Nic
21.02.23
✎
08:22
|
Создавать реквизит, совпадающий с предопределенными - жутко плохо. Не делай так.
|
|||
2
FrostBite101
21.02.23
✎
08:38
|
(1) Я прекрасно знаю, что делать так нельзя. Суть моего вопроса "Когда используется ТО, а когда ЭТО". Когда использовать подчиненность, а когда создать свой реквизит (без подчиненности)
|
|||
3
АгентБезопасной Нацио
21.02.23
✎
08:40
|
(2) кроме собственно структуры данных, есть еще структура метаданных в конфигурации. у которой либо включена подчиненность, либо нет.
|
|||
4
FrostBite101
21.02.23
✎
08:43
|
(3) Так я и спрашиваю когда используется один способ, а когда другой. Подчиненность выставляется в настройках метаданных объекта конфигурации, а реквизит я создаю сам.
|
|||
5
FrostBite101
21.02.23
✎
08:45
|
(4) В каком случае мне выставлять подчиненность в объекте справочника метаданных, а когда можно просто создать реквизит, типо "Владелец". - вот так может проще
|
|||
6
Chai Nic
21.02.23
✎
08:46
|
(2) Обычно не используют подчиненность, когда нужно скрыть от пользователей факт подчиненности объекта.
|
|||
7
Kigo_Kigo
21.02.23
✎
08:47
|
Ничего не понятно, но очень итересно, но осуждаю, дай пример
она подчиненость либо есть либо ее нет, если хочешь стандартными средствами к одному элементу набор элементов не пересекающихся с первым, то лучше использовать подчиненость к примеру подразделения, их набор уникален для каждой организии |
|||
8
Fish
21.02.23
✎
08:48
|
(4) Когда нужно использовать подчиненность - используют подчиненные. Если же подчиненность не нужна - то её не делают. Странный вопрос.
|
|||
9
Kigo_Kigo
21.02.23
✎
08:50
|
не так выразился
если хочешь стандартными средствами к одному элементу набор элементов не пересекающихся с первым* читать как если хочешь стандартными средствами к одному элементу первого спр, набор элементов второго справочника(уникальный) тогда подчиненость нужна тут даже при выборе реквизита стандартно указываешь связь и платформа сама отрабатывает отбор |
|||
10
FrostBite101
21.02.23
✎
09:05
|
(9) Тоже самое можно сделать просто создав реквизит "Владелец" со ссылкой на владельца. Это точно такая же связь один ко многим. Все эти отборы автоматические тоже можно настроить. Тогда в чем принципиальное различие? В чем архитектурное обоснование использование того или другого.
|
|||
11
Serg_1960
21.02.23
✎
09:07
|
Принципиальная разница, имхо, только в одном: в терминах реляционных баз данных, между таблицами (справочник-владелец<-->подчиненный справочник) устанавливается связь "один-ко-многим" и эта связь "поддерживается" на уровне платформы 1С и сервера БД (в случае клиент-серверный вариант).
|
|||
12
FrostBite101
21.02.23
✎
09:18
|
(11) Вот пример в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так? Почему для банка и банк. счета было выбран реквизит, а для физ лица и банк. счета - подчинение?
|
|||
13
Garykom
гуру
21.02.23
✎
09:20
|
(0) пометка/удаление подчиненных при пометке/удалении владельца
|
|||
14
Garykom
гуру
21.02.23
✎
09:21
|
И да можно аналогично не использовать ТЧ у объектов, вместо этого создать новые "сущности" и привязать их "владельцем"
Но это изврат |
|||
15
Aleksey
21.02.23
✎
09:23
|
(12) а разве банковский счет не подчинении физлицу? Т.е. 1с не умеет чтобы элемент был подчинении двум объектам методанных. Поэтому и банк реквизит
|
|||
16
Garykom
гуру
21.02.23
✎
09:24
|
Особенность системы/платформы 1С в куче дополнительных "лишних" сущностей/объектов и процедур/функций
Для "упрощения" и стандартизации разработки Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результат = процедура Или справочники/документы тоже разница небольшая, обязательные реквизиты по умолчанию Код и Наименование vs Дата и Номер Ну и проведение документов - по сути которое можно вручную реализовать для справочников |
|||
17
hockeyist
21.02.23
✎
09:28
|
(16) Справочники и документы - это наше все. Не будь этого разделения, 1С не стала бы тем, чем она стала.
|
|||
18
Garykom
гуру
21.02.23
✎
09:30
|
(17) Это хрень если честно
Вместо разделения в Конфигураторе на всего две ветки-группы "Справочники" и "Документы" Лучше бы сделали возможность произвольного создания своих "Групп" И для каждого объекта метаданных выбор что это Справочник или Документ и свойства по умолчанию меняются |
|||
19
Garykom
гуру
21.02.23
✎
09:31
|
(18)+ * и свойства/поведение по умолчанию меняются
|
|||
20
hockeyist
21.02.23
✎
09:32
|
(18) Вот и сделай свою систему с группами. И она никому не интересна будет. А справочники и документы "зашли". Потому что помогают неопытным разработчикам делать учетные системы
|
|||
21
Serg_1960
21.02.23
✎
09:32
|
(10) "Это точно такая же связь один ко многим." - да, "один ко многим", но не "точно такая же". Как я выше отметил, отличия на уровне поддержки.
(12) Опять таки всё дело в уровне поддержки. Программный уровень поддержки и/или на уровне конфигурации - более затратные методы, но они же более гибкие. Например, такая связь может быть изменена или может быть ситуативной. Что более оптимально - решают методисты. То же самый принцип подхода, имхо, что и в "константы или справочники" - постоянная информация или условно постоянная? (это риторический вопрос) |
|||
22
Garykom
гуру
21.02.23
✎
09:33
|
Или вот Регистры накопления изврат тоже
Почему тогда не сделали разделение на три "сущности" "Регистр остатков", "Регистр оборотов" и "Регистр остатков и оборотов" |
|||
23
Garykom
гуру
21.02.23
✎
09:33
|
(22)+ оно же в запросах один хрен раздельно!
|
|||
24
FrostBite101
21.02.23
✎
09:34
|
(13) вот это вот очень важное отличие, что-то типо каскадного удаления.
|
|||
25
Garykom
гуру
21.02.23
✎
09:34
|
(24) в других субд (в по сути на низком уровне в 1С) это решается ключами/триггерами
|
|||
26
Garykom
гуру
21.02.23
✎
09:36
|
(20) Дада. Неопытным.
А потом большие системы типа ERP выглядят как будто эти неопытные их и проектировали/писали И чтобы разобраться приходится быть дико опытным и то куча матов что к чему и зачем |
|||
27
Garykom
гуру
21.02.23
✎
09:38
|
Или вот почему в Конфигурторе до сих пор нет "своего фильтра по метаданным"?
По типу как отбор по подсистемам или захваченные из хранилище, но сам накидал что тебе надо в фильтр и видишь только их при установке своего фильтра! Было бы сильно удобней при доработках |
|||
28
Fish
21.02.23
✎
09:40
|
(27) Сделай подсистему "Мой фильтр" и сам накидывай в неё, что тебе надо. :)))
|
|||
29
Serg_1960
21.02.23
✎
09:41
|
Garykom предлагает вернуться к макроассемблеру?
"Кац предлагает сдаться"(с) |
|||
30
Лирик
21.02.23
✎
09:41
|
(16) Выпилить все и оставить С+. :)
|
|||
31
FrostBite101
21.02.23
✎
09:41
|
(27) В едт вроде подобные отборы есть, ну или на крайний случай плагины)
|
|||
32
НафНаф
21.02.23
✎
09:43
|
(2) общая тенденция новых конфигураций - не использовать встроенную подчиненность. Например, ДоговорыКонтрагентов не подчинены справочнику Контрагенты, а имеют реквизит Контрагент.
|
|||
33
Bigbro
21.02.23
✎
09:47
|
(32) потому что контрагенты меняются как перчатки (юрлица) а договор с компанией продолжает работать.
|
|||
34
hockeyist
21.02.23
✎
09:50
|
(0) Можно использовать и так и так. Лично мне больше нравится вариант без использования платформенной подчиненности. Он нагляднее. Открываешь справочник Договоры, видишь реквизит Контрагент и все сразу понятно. А с платформенным механизмом все не так очевидно
|
|||
35
Chai Nic
21.02.23
✎
09:50
|
(16) "Например разделение на процедуры и функции оно нафик не нужно, хватит функций, которые не обязаны возвращать результа"
Оно нужно, если бы в 1с были "строгие" функции, которые не меняют вызывающий контекст. А так да. Всё можно делать функциями, без ущерба для. |
|||
36
Chai Nic
21.02.23
✎
09:53
|
+(35) И у функций есть одна удобная побочка для отладки, их можно вызывать через табло и в отладчике. А процедуру нельзя.
|
|||
37
hockeyist
21.02.23
✎
09:53
|
+(34) Да, и совсем забыл. Свой механизм гибче. Платформа допускает только одного владельца
|
|||
38
Serg_1960
21.02.23
✎
09:54
|
(32) Имхо, если в конфигурации появляются справочники "Партнёры/контрагенты" и "Контрагенты/Контрагенты", то подчиненность тоже начинает зависать в воздухе. Возможно методисты со временем разродятся и появится иерархия с подчиненностью, скрестят ежа и ужа :)
|
|||
39
Serg_1960
21.02.23
✎
09:55
|
(уходя) Отличная тема, пятничная.
|
|||
40
Garykom
гуру
21.02.23
✎
09:57
|
(36) Недоделанность отладчика это отдельная вещь
|
|||
41
НафНаф
21.02.23
✎
10:04
|
(33) Договор так-то к юр. лицу относится. С другой стороны менять можно как обычный реквизит, так и Владелец - разницы никакой.
Вся разница в том, что если я помечу на удаление владельца, то пометятся и подчиненные. Возможно дело в правах доступа. |
|||
42
lodger
21.02.23
✎
10:04
|
(38) "Партнёры/контрагенты" - это вызов времени такой. когда у твоего делового партнера на вывеске ГК Крутые Пупки, а когда начинаешь писать бумаги, то там ООО "Розовый пупочек" в точке А, его филиал в точке Б, ООО "Нежный пупочек" в точке А по другой части договора, ООО "Левая Пятка" по всем точкам принимает дела по ИТ-сфере. а всё вместе - это один партнер, ты с одним CEO договариваешься обо всех аспектах.
но вот каким раком это реализовано в инфраструктуре 1с это конечно мрачно =( |
|||
43
unregistered
21.02.23
✎
10:09
|
(12) > в управл. небольшой фирмой. Есть банковский счет, в нем реквизит "Банк". Соответственно связь один ко многим, Банк имеет множество банк. счетов. Это сделано через реквизит, а вот тут же. Физическое лицо является владельцем бан. счета, то есть выставлено подчинение в объекте метаданных. Почему так?
Потому что УНФ ведёт в первую очередь учёт Контрагентов, ФизЛиц и Организаций. Поэтому с точки зрения учёта важнее кому принадлежит банковский счет - какому контрагенту, физику или организации. В 99% случаев пользователя интересуют вопросы "Какие банковские счета есть у этого контрагента?" или "Чей это банковский счёт?", а не "Какие наши контрагенты имеют расчетные счета в этом банке?" или "В каком банке расчетный счет контрагента? (первичен контрагент, а не банк)". Если бы авторы УНФ писали конфигурацию "Управление Центробанком РФ", то владельцем элемента БанковскиеСчета были бы элементы справочника Банки, а Контрагенты и ФизЛица - обычными реквизитами. PS Выбор между установкой связи по владельцу или имитация этой связи через реквизит может быть обусловлен двумя причинами. Во-первых, бытовой логикой задачи. Как в примере с банковскими счетами, где пользователю важнее какому контрагенту или физлицу принадлежит счёт, а не то в каком банке он открыт. С точки зрения пользователя Контрагент является владельцем счёта, а банк - всего лишь кредитная организация, предоставившая услугу ведения счёта. Во-вторых, теми удобствами, которые предоставляет платформа в рамках связи по владельцу. Всегда проще воспользоваться тем, что уже есть и работает из коробки, чем имитировать это собственными инструментами. |
|||
44
АгентБезопасной Нацио
21.02.23
✎
10:35
|
(20) ну делали же на клюшках систему учета на справочниках. Забавно было
|
|||
45
Bigbro
21.02.23
✎
10:42
|
мне лично видится разница лишь в том насколько часто вам требуется плоская выборка без учета владельца либо по нескольким владельцам либо замена владельца и так далее.
если это нужно часто то встроенный механизм подчинения с владельцем не особо нужен, проще реквизит. |
|||
46
Bigbro
21.02.23
✎
10:44
|
в моем примере с договором - у вас центральным объектом является договор, как написано в (42), а какие там юрики реально висели получали отправляли документы в какие периоды - это уже нюансы, сегодня это одни завтра другие а владелец Вася Пупкин один и тот же и он наш постоянный и уважаемый клиент, с которым сотрудничаем уже десяток лет, и все нюансы нашего сотрудничества в договоре фиксированы. а контрагент в данном случае всего лишь реквизит по которому отправляем получаем деньги.
|
|||
47
azernot
21.02.23
✎
10:55
|
(0) >Когда мне стоит делать подчиненность, а когда собственный реквизит?
Ответ очень прост. Когда подчинённый элемент абсолютно не имеет смысла без владельца, вообще ни при каких обстоятельствах - делается подчинённость. А когда он в принципе может существовать и без владельца - это всего лишь реквизит. Я могу себе представить банковский счёт (как элемент справочника) без ссылки на справочник Банки. Например, счет в зарубежном банке, реквизиты указываются текстом, также видел счёт с названием "Наличными курьеру" :) А вот абстрактный, неизвестно чей счёт в банке - нонсенс. |
|||
48
Anton1307
21.02.23
✎
12:23
|
Если под понятием "Реквизит "Владелец" ты понимаешь именно реквизит с именем "Владелец" - ты не сможешь добавить такой реквизит.
Равно, как нельзя создать реквизиты "Наименование", "Код" и "ПометкаУдаления" |
|||
49
mistеr
21.02.23
✎
12:49
|
(2) Предлагаю поставить вопрос по-другому. Когда НЕ стоит использовать подчиненность, а делать свой реквизит?
Мой ответ: когда подчиненность уже занята другой связью. Во всех остальных случаях не выпендривайся и делай как вендор задумал. P.S. Ладно, есть еще один исключительный случай. Когда ты мнишь себя архитектором 80 уровня и пытаешься изобразить на платформе 1С не учетную систему, а нечто экзотическое. |
|||
50
hockeyist
21.02.23
✎
14:34
|
(49) Что такое учетная система по вашему?
|
|||
51
Лирик
21.02.23
✎
14:36
|
Весь функционал реализованный "Владельцем" можно реализовать собственным кодом (уникальность кодов, раздельную нумерацию, запрет незаполненного значения, отбор связанных списков и т.д.). Другой вопрос зачем, если есть штатный механизм. Посему согласен с (49).
|
|||
52
mistеr
21.02.23
✎
15:46
|
(51) Кроме каскадного удаления
|
|||
53
mistеr
21.02.23
✎
15:48
|
(50) Вопрос на монографию. :)
Это к Гению, он любит потрындеть на эту тему. |
|||
54
НафНаф
22.02.23
✎
07:45
|
И минусом ко всему - владельцу нельзя присвоить определяемый тип
|
|||
55
НЕА123
22.02.23
✎
09:30
|
(0)
в 7 у справочников не было табличных частей (что, на мой взгляд, правильно). подчиненный справочник - аналог табличной части. |
|||
56
АгентБезопасной Нацио
22.02.23
✎
09:36
|
(55) там вообще не было "частей" в лучшем случае - [одна] "часть", у доков. Не, конечно, решения были, но все равно лучше бы искаропки.
|
|||
57
Chai Nic
22.02.23
✎
09:39
|
(55) Табличная часть это удобно. Это позволяет использовать вторичную зависимость один ко многим без явного ссылочного объекта со всеми его особенностями.
|
|||
58
НЕА123
22.02.23
✎
09:40
|
(56)+1
я уже подзабыл... действительно, 1 ТЧ у дока. корячились. да. |
|||
59
НЕА123
22.02.23
✎
09:41
|
(57)
ну... мало что можно у справика в ТЧ. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |