Каскадная связь таблиц. Аналог в 1С.
Есть обычная БД. В ней три таблицы.

Таблица 1. Список изделий
ИД
И куча прочих полей

Таблица 2. Список операций
ИД
ИД  для связи с таблицей 1
И куча прочих полей

Таблица 3. Кто выполняет операцию.
ИД
ИД для связи с таблицей 2
И куча прочих полей

Для примера такая организация.
Изделие 1
-- Операция 1
---- Работник 1
---- Работник 2
-- Операция 2
---- Работник 3
---- Работник 5
-- Операция 3
---- Работник 2
---- Работник 4

На справочниках-то понятно три справочника, Основной. Подчинённый первому. Подчинённый второму.
А как это сделать для дока? В доке хранить не вариант, потому потом начинается движении по этапам, и док держать не хорошо каждый раз чтобы обновить на каком этапе сейчас это все идёт. Регистры не ссылочный тип.
Как вариант тоже напихать ИД.
Но как это все обработать и красиво показать в документе?

не очень понятно что нужно.
Если для ввода то, например:
Документ. в нем 3 таб. части "Список изделий", "Список операций", "Кто выполняет операцию". В каждой таблице обязательное поле ИД строки, в подчиненных еще поле ИД владельца.
А отображать можно деревом.
Примерно как сделан стандартный документ Прайс-лист в ЕРП и обрезках.

(0) Банальный РС Связи
С тремя измерениями (Изделие, Операция, Работник)
Ресурсы не нужны но можно туда даты и прочее, если периодический не делать РС

(1) Да вот такое и нужно.
Блин без ИД никак получается, то бишь переложить на 1С контроль ссылочной целости не удастся.
(2) Как бы вариант, но не нравится он мне. Усложнение схемы получается.

В общем опять все лапками. На 1С это переложить не получится походу.

(3) Это не усложнение а упрощение себе жизни
Чтобы изменить не надо доки перезаписывать и перепроводить

(4)+ В целом есть простое правило:
Ссылка/id на Родителя/Владельца сохраняется в Подчиненном объекте (один ко многим)
Или во внешнем объекте/таблице связей обе ссылки/id (многие ко многим)

А можно в одной таблице все хранить с 3мя колонками :)

(6) Нужно больше треша! Можно всё хранить в одном реквизите типа "ХранилищеЗначений". Загнать туда дерево значений.

(4) Сам то он не заполниться. Надо будет в него писать. Обработчики надо рисовать.
Да и получится я все солью в один регистр где будет много дублирующей информации.

Изделие 1- Операция 1- Работник 1
Изделие 1- Операция 1- Работник 2
Изделие 1- Операция 2- Работник 3
Изделие 1- Операция 2- Работник 5
Изделие 1- Операция 3- Работник 2
Изделие 1- Операция 3- Работник 4

Мне места на диске не жалко конечно. Но как-то оно не то.

(5) Но это работает 1С только в справочниках.
Регистры не ссылочный тип.

(9) не тупи
реквизит Основание у документов
и в РС пишутся ссылки на твои ссылочные тыпы (справочники или документы Изделие, Операция, Работник)

(6) А если у метя каскад из пяти, десяти таблиц?
Хотя в типовых походу так и колбасят

(8) ты думаешь запись в РС занимает больше места чем еще реквизиты в объектах метаданных?

(10) туплю, не понимаю я твоего предложения, сорри.
Можно как-то на пальцах, или пример какой?

Справочник "Изделия"
Справочник "Работники"
Справочник "Операции" или Документ "Операция"

РС "Связи", измерения:
1. "Изделие" тип СправочникСсылка.Изделия
2 ."Операция" тип СправочникСсылка.Операции или ДокументСсылка.Операция
3. "Работник" тип СправочникСсылка.Работники

(12) Нет, но так сильна раздувается таблица.
В (0), в примере, у меня одна в первой таблице, три записи во второй и шесть в третей.
Ты мне предлагаешь свали все в одну. А как же ароматность записей? Первая нормальная форма и все такое?

(14) И куча прочих полей из (0) я куда дену? Выкинуть?

(15) чето непонятно какую проблему решаешь, и пятница только завтра

(15) Еще раз
Ссылка/id что в отдельной новой таблице
Что в существующей таблице еще новые реквизиты
Одинаково места!

(16) Это уже платная услуга
Раскидать по справочникам или в ресурсы РС

(19) Ну и будет РС с кучей ресурсов которые тупо дублируют друг друга.
Или моя твоя не понимает?

(17) Ща картинку нарисую. Ну попробую по крайней мере.

(20) ты реляционные базы данных (модели сущность-связь) и всякие нормальные формы с нормализацией изучал?

(22) Вот я тебе про эту нормализацию и пытаюсь рассказать. Походу фигово.

(0) 4й справочник. кода нет, наименования нет, одно поле составного типа; в типе три твоих справочника, рулить типом на уровне элемента, вложенность групп 3, подчинение элементам

(24) Так у него еще ресурсы есть

гляньте, как справочник ключи аналитики чего-то там в типовых устроены

в справочник пихаете свои реквизиты. а в регистры - одну сцылку на этот самый элемент справочника - ключ аналитики

??

всё не читал

(25) Первые три справочника живут своей жизнью; тащат там в себе что надо. этот 4й только для связи

Ну так в документе как указать ресурсы на каждый уровень имея только 4ю аналитику?

(23) а на практике излишняя нормализация нафик не нужна
да она экономит место
но замедляет скорость

(28) Это уж как реализуешь работу с этим справочником в документе

(21) А проблема-то в чем? Заводи справочники, документы, да что угодно - заводи реквизиты для связи.

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

Какие у тебя требования к решению, что хочешь получить? Не в структуре данных, а конечный результат какой?

(31) Да пытаюсь изобразить рабочее место оператора для цеха. Чтобы максимально простое и информативное было.
То что мне интерфейс придется лапками рисовать, я уже смирился.
Раньше он был на Дельфи писан. Но вот решили заканчивать с лоскутной автоматизацией, собираем все единую кучу.
Ладно, в общем надо пробовать и так и этак.
Идей тут накидали чуток.

я до самого конца так и не понял в чем проблема...
ну есть 3 уровня подчиненности сущностей и что?
бывает и 4 и хоть 10.
если оно заранее известно - так вообще никаких проблем.
а если может быть разным - то лучше сделать как уже выше писали.
единый справочник с подчинением элементам и в нем одно из полей тип - который будет определять глубину вложенности.
и все, набивай туда что хочешь, хоть 20 подчиненностей хоть 50.

(21) Так весь один 1С такой - на ссылочности
ERP - производство
1. Номенклатура
2. Ресурсная спецификация
   - Осн. изделие - номенклатура
3. Выпуск продукции
   - Спецификация - ресурсная спецификация...

(33)Зачем мне справочники? Это не справочная информация же по идее.
(34)С регистром такая фишка не прокатит. Он не ссылочный тип.

(35) У тебя же ссылочная информация можно на документах или справочниках (Выпуск продукции-документ)
И вoобще нарисуй это в SQL с первичными ключами и реализуй где хочешь.

(0) Можно такую структуру:

Справочник Номенклатура
   Бизнес-процесс Операция1...3 (можно завести ТЧ Продукция)
       Задача.Исполнитель (в шапке ссылка на БП-операцию)

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

много букв, в дополнение (26)

Ключи аналитик учета в ЕРП, КА, УТ
https://clck.ru/3GEtAh

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

А давайте дружно попросим 1Ску сделать таб.части в таб.части, и будет всем щасте!

(38) жизнь такова, что чаще всего необходимо все существенные данные переносить из справочника в документ, либо хранить их (данные) в периодических РС. Ибо жизнь изменчива, а документ одномоментен.

(40) Да простая там смысловая нагрузка.
Оператор сделал док.
Рисует некий маршрут как некая фигонина будет двигаться по операциям и кто эти операции будет выполнять.
Так как док содержит кучу инфы, и их несколько вариантов(не дублировать же это все в каждом виде дока), он зарывается.
Поэтому маршруты мне надо вынести в отдельные регистры.
А там уже пик сканер ответственный что пришло на текущую операцию, то бишь записали в регистр дату и время прихода на операцию, если пикнули - а он предыдущую операцию не прошел, то злобный бип(я там сирены прикрутил, вместо спикера уже) и большая красная надпись верни назад и диспетчеру соответственно сообщение придет там чебурашки косячить пытаются.
На операции чебурашки чего там ваяют, отваяли приложили карточку к считывателю, опять записали что такая чебурашка в дату, время и параметры его ваяния. Ответственный за операцию пикнул сканером  и передал на следующую операцию, опять пишем дату, время и параметры оперции.

(41) Дык дерево же есть. Геморройно конечно события обрабатывать, но рисует красиво.

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

(36)Это в SQL у меня уже есть. См(21). Но блин все это писалось разными людьми в разное время. Еще и на разных языках.
Решили вот в общую базу завести.

(45) Так если вам нужен документ - делайте в нем, в чем проблема? В ЗУП так связаны табличные части Начислений и показателей по идентификатору. Я думаю ещё в куче конфигураций. Вы сами определитесь что вам нужно...

(0) 1C тоже хранится в обычных таблицах
вопрос, в том, насколько хочешь ты упражняться в логике управления этими связями

(47) Да я уже сваял два регистра.
В одном операции, в другом рабочие.
Теперь вот выбираю что использовать в качестве идентификатора для связи.
Если в SQL это можно на движок базы положить всякие составные ключи, триггеры там.
То тут мне надо самому следить.

Кстати, а как захныкать регистр чтобы пользователь его не нашел?

(48) Да вот хотел 1С заставить следить, не удалось.

(49) гляньте (37), там будет ссылочная целостность

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

(51) Так мне на каждом этапе еще кучку параметров записать, в регистрах это идеально, там ресурсы есть.
Но попробую. вдруг чего и там интересного нарою.

(53) в БП и Задачах есть реквизиты и таб.части, они круче

(52) Я же не смогу бизнес-процесс на уровне пользователя править.
Или можно?
Как-то я в них не силен. Щас почитаем.

Можно завести спр. Задачи, подчиненный сам себе (иерархия элементов).

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

(55) БП по сути документ, его можно исправлять и записывать.

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

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

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

(58) У нас гибкие цепочки. Не прокатит.
Изучим, на улице все равно делать нечего, штормит, пороюсь пока по бизнес-процесам.

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

Карта маршрута БП может быть тривиальной: старт - точка операции - проверка на конец - финиш.




Весь маршрут можно задавать в таб.части БП

(49)
>> Кстати, а как захныкать регистр чтобы пользователь его не нашел?

А как же ОН его найдёт ?
Доступа к "Все операции"  у пользователя нет. Или есть ?

И даже если найдёт (перейти по ссылке).
У пользователя права только на чтение и Просмотр.
Пусть смотрит, хоть засмотрится.

Справочник Изделий,справочник Операций, документ с реквизитом Изделие и ТЧ с колонками Операция, Исполнитель и может еще чота что захочется.

(64) БП с задачами лучше. Задача может отражаться у пользователя в списке "Мои задачи". Её выполнение можно фиксировать в реквизитах задачи, независимо от других задач. Можно параллелить процесс по разным исполнителям, можно настроить адресацию по роли. Короче, БП круче

(62) Не будет. Но можно по ссылке же.
(63) На запись же тоже будет.
Или запись вынести в общий модуль на сервере с привилегированным режимом.

(44) ты не путай структуру хранения данных и их визуальное представление

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

+ (68) на одной операции, конечно

NoSQL отлично подходит для решения подобных задач. Можно тупо хранить данные в иерархическом виде а ля json

(70) У него обычные творческие муки в архитектуре обычной реляционной базы. Просто они лишние. Документ с двумя связанными между собой ТЧ (1) в скл варианте и будет, то что он хочет - по ключам и лапки не нужны. Только данные будут в документах, а не регистрах. Можно самому по нескольким регистрам разложить, либо в один, но будет дублирование данных (2). Просто не совсем понятно, что именно не устраивает - от этого никуда не деться.  Множиться будут либо строки либо колонки. Конечно, в идеале бы так чтобы таблиц вобще не было, просто - раз и данные на форме появились
(0) нужно искать не в технической части, а в логике процесса. Если, например, сотрудников фиксированное количество, то они могут быть реквизитами одного РС. Будет одна таблица и в ней в каждой строке будет дублироваться только изделие, тк выносить изделие в отдельную таблицу с одной колонкой смысла нет. Нууу это нормально
"Прочие данные" вынести в доп свойства или еще какие то таблицы

Но в целом желание сделать с максимальным отсутствием избыточности понятно

гм (2) не совсем правильно понял, это о другом. Связи тут кажутся лишними, хотя от задачи зависит, в частности от "Прочие данные" изделия, например. Если они статические, то не надо, если динамические то надо

(67) Хорошо оформить на экране тоже важно. Операторы будут меньше тупить и ошибок делать.
(68) До десятка. Плюс надо записать на них время и материалы.  чтобы потом концы найти когда брак разгребать будут.
(70) Но хотелось бы в 1С реализовать.
(71) Ну во первых док не прокатывает, потому что после запуска он переводится в режим только чтение.
Во-вторых менять док не в концепции 1С.
В-третьих доки разного типа будут и бегать по их табличным частям потом не айс. Добавится доки и опять все переписывай?

Да и в каскаде может быть до 5-6 таблиц. Это я простой вариант привел, для примера.

(73)В том и прикол что они динамические, иначе бы я их тупо их в справочник загнал.

(74) попробуйте подойти с методической стороны. Десяток исполнителей на одной операции общего маршрута это что за операция такая, постройка атомного реактора что ли, а общий маршрут - его запуск и добавление в каскад других реакторов? Поэтому можно разбить маршрут детальнее, тогда исполнителей, и остального, станет меньше, этим можно варьировать. Для исполнения лучше отдать это на откуп кому то, обычно это планово диспетчерский отдел + нормативщики, а не рабочий на месте. Цех должен иметь возможность вносить корректировки для конкретной работы, но остов лучше создавать грамотному в логистике работ специалисту.

Это конечно не решает проблемы универсальности хранения данных: материалы, оборудование, технологическая информация и так далее - все это раскладывается по разным таблицам, вопрос масштабнее, чем казался в (0) :), поэтому для него и ресурсы нужны, "по-легкому" не получится

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

>>которую невозможно формализовать - синоним бардака
формализовывать должен компетентный специалист, но с возможностью корректировок со стороны цеха
динамика - затратно для прога и хорошо всем, ведь и к программе вопросов нет )

формализовывать сам процесс конечно, для этого им нужен инструмент

(75) Для этого у меня технологи есть.
И так у же раздробили как смогли. Народа много потому что у каждого свои допуски. Нельзя сделать универсального бойца, электрик-механик-сварщик например. Хотя на операции они могут быть задействованы всего на пару минут.
Так технологи с логистами и формируют эти маршруты, и следят за ними. У меня они операторы.
В цеху тока пикать сканером могут.
(76)Элемент бардака конечно присутствует, так как это заказное производства, нет четкого понимания что делаем сегодня, чего завтра. Но посты обработки уже сформированы, и поэтому надо подстроится под них. Да там зачастую оптимально, но переоборудование дело дорогое и не быстрое.

Ветвлений нет. Движение только вперед. Линейное.

(78)Вот что-то пытаемся нарисовать. Потому сейчас все посты изолированы и максимум, что на сейчас сделали это льем в одну базу периодически. Хоть аналитику собрать можем.

В общем пока идея реализована такая.
В регистры пишется гуид. Контроль целостности прописан в самом модуле регистра.
То бишь повторил реляционную модель MS SQL.
Не нравится мне это, но работает и довольно просто получилось с реализацией. Но явно где-то есть грабли, пока не наступал.

(80) Не нравится мне это...

(81) Согласен. Не по 1С-ки получается.