Перенос записей между сущностями

[Paganini]

Здравствуйте!

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

Спасибо!

[alcompstudio]

Добрый день! Да у меня тоже есть подобная необходимость, но думаю, возможно лучше сделать в таком случае все на основе связанных записей, но предусмотреть удобное "отслеживание", фильтрацию при принадлежности связанных записей к той или иной сущности. И для таких случаев "переноса"/"миграции" записей нужно будет задействовать фильтры, чтобы выделить в нужный момент нужные записи в одной сущности и "переподключить" их к другой (т.е. оборвать связь, если нужно с первой сущностью и создать с другой). Это, кстати, можно будет выполнять при помощи автоматизации, думаю, должно получиться. Назначить по фильтрам связанных записей действие на кнопку - и при нажатии "отобранные" связанные записи "перекочуют" в запись другой сущности.

Для этого нужно создать 3 независимые (а можно в принципе и зависимые) сущности:

Сущность 1 (для "первоначальной" связи/подключения к ней)
Сущность 2 - собственно, записи из которой будут "переноситься/мигрировать"
Сущность 3 - "принимающая" записи сущность.

Вот в процессе автоматизации должны будут "переподключаться" связанные записи между Сущностью 1 и Сущностью 3.

По логике и при правильном подходе - внедренные формулы и функции должны будут правильно срабатывать как в первой сущности, так и в 3-й. Главное, чтобы была связь в конфигурации (поле с Сущностью 2) как для Сущности 1, так и для Сущности 2.

Как-то так.

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

Но это мое мнение, решать как лучше, конечно, нашему разработчику

[support]

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

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

Я бы предложил разделить процессы и изделие.

[Paganini]

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

Например, запись, которую нужно перенести, это совокупность из VARCHAR (256), LONG TEXT и, скажем, BOOLEAN. Они сопоставлены к принимающей сущности по ID ее полей, и там точно такие же типы полей (а иначе сопоставление просто не выполняется). Ок.

Дальше варианты действия пользователя:

• Вдруг в донорской сущности пользователь решил просто грохнуть BOOLEAN. С точки зрения принимающей сущности это вообще не страшно -данные просто не попадут по причине их отсутствия.

• Если пользователь решит добавить к уже установленному сопоставлению поле - флаг в руки, сопоставление нужно просто пересоздать.

• Если пользователь решит в принимающей сущности заменить сопоставленный BOOLEAN на, скажем, MEDIUM TEXT, то прога, прежде чем что-либо вообще менять, видит флажок, сигнализирующий о наличии сопоставления, и не позволяет менять это поле, отправляя красивой ссылочкой чувака к той сущности, где есть эта привязка. Ну либо вариант тут же разорвать связь с предупреждением о вменяемости (ну вдруг там сущность вообще пробная, и разорвать сопоставление не страшно).

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

А еще можно переносить формульные данные в виде вычисленного значения Не знаю зачем, но интуитивно кажется полезным.

А самое важное - эта операция кажется проще, чем настраивание сложных вложенных сущностей и накручивания хитрых фильтров. А простота - это главный конёк "Руководителя"

Просто мысли.

А еще можно замутить графическое представление логики приложение, автоматическая генерация схемы Для тех админов, кто вконец запутался во взаимосвязях.И вообще реализовать настройку связей путем таскания блоков по экрану мышкой ) Этакий BPML.

[support]

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

Да, запланировал такую возможность.