впервые столкнулся с ситуацией круговой зависимостью между двумя объектами, причем это не выглядит глупо в данном случае, а даже как-то интересно, и я до сих пор не могу решить как к этому относится: как к полезному трюку или как к тому, чего делать как раз не стоит.
сейчас постараюсь описать, как это сделано, это потребует некоторых усилий
вот представьте запись/объект в которой все поля разделены на три секции. Но если посмотреть на объект, то вы не увидите те поля, а только пару ключевых мониторинг - полей для каждой секции. Ну так где все те поля, что содержать основную информацию?
все они находятся на другом, дочернем объекте. Дочерний объект имеет три рек тайпа, вроде "Секция 1", "Секция 2" и т.д. У каждого рек тайпа есть свой лейаут на котором выложены те поля, которые принадлежат именно к данной секции. Выглядит занятно, но для чего это все и как это работает, спросите вы. А вот как.
В момент создания родительной записи, создаются три дочерние записи. Но на родительском лейауте нет рел листа для дочерних записей, зато есть - и это самое главное - в каждой из трех секций есть лукап на тот дочерний объект, который содержит линк на соответствующую запись, т.е. в Секция 1 есть лукап-линк на дочерную запись с рек тайпом "Секция 1" и соответствующими полями на ней. Интересно?
и зачем это было сделано? пока я получил такие ответы:
(1) удобный стандартный интерфейс родительской записи, где на самой записи пользователь видит только ключевые параметры, в том числе и те что можно через формулу вытянуть с нужного лукапа, а если пользователю нужно больше деталей - то кликает на лукап-линк и видит их на соответствующей дочерней записи;
(2) якобы так проще работать с вал рулами, которые сидят на дочерней записи и привязаны к конкретному рек тайпу. Если не получилось апдатировать одну секцию-запись из-за вал рула - то это не мешает работать с другими секциями или родительской записью.
(3) посекционный мониторинг того кто и когда редактировал инфу в секции (якобы это требование)
вот такая штука...
что вы думаете об этом?
Интересно придумано!
Всегда завидовал таким людям, которые могут вывернуть свой мозг так.
Может я что-то не понял, но круговой зависимости не увидел, редактировать поля все равно только на дочерних объектах.
Скорее всего это даже правильный подход, с точки зрения нормализации БД, но как же это дорого по Data Storage.
Увеличение занимаемого места в 3 раза с учетом конского ценника на него, думаю не каждая компания сможет позволить, если таких объектов сотни тысяч.
1 - если честно то сомнительный плюс
2 и 3 - выглядят уже куда бодрее)
наверное имелось ввиду что МasterObject имеет 3 лукапа на ChildObject, в то время как ChildObject связаны MasterDetail c MasterObject - вот и получается что они залинкованы друг на друга
я не знаю, является ли это нормализацией. основные поля выведены в дочерний объект, но сами дочерние записи не идентичны а уникальны по содержанию в пределах одной родительской записи. там не может быть две Секции 1 для одного родителя. фактически одна запись просто расщеплена на несколько уникальных фрагментов.
там на самом деле много секций, и много записей получается. но сам объект - не низовой носитель базовых данных (как какая нибудь транзакция), а является отчетным бизнес процессом, что случается раз в год, то есть там не ожидается много записей при любых обстоятельствах
да, видели бы вы как это выглядит это в Схема Билдере - дочерний объект от которого идет веер лукапов обратно к родителю
еще есть мнения о таком подходе?
В принципе 2 и 3 достижимы с использованием только одного объекта, но скорее всего большими усилиями по сравнению с таким разделением. 1 - плохенько, но попытаться то же самое сделать можно за счёт дублирования полей и создания парных "summary"/"detail" секций, "summary" выносятся в шапку, а "detail" - вниз layout'а. Но выглядеть это будет не так красиво 
Так что - в свете имеющихся данных, вполне себе элегантное решение.
