Doresc sa construiesc un arbore decizional pentru o aplicatie de HR. Arborele trebuie sa fie construit in aplicatie, de catre un utilizator, si in mare ar functiona cam asa: compania care foloseste aplicatia trimite un email cu oferte de job-uri; daca exista un anumit tip de interactiune din partea destinatarului (deschide e-mail, da click pe un link din e-mail etc.) atunci trebuie sa inceapa un proces decizional automat care poate imbraca forme de genul:
Destinatarul a deschis e-mail-ul:
Da → Aplic un flag de destinatar verificat
Nu → Aplic un flag de destinatar neverificat
Destinatarul a dat reply la e-mail:
Da → Aplic un flag de destinatar verificat → Ii trimit un alt mail
Nu → Aleg sa nu fac nimic
Sunt inca in faza de documentare, caut solutia tehnica optima pentru salvarea arborelui in baza de date, precum si parcurgerea lui ulterioara cu posibilitatea de a sti in orice moment unde anume se situeaza destinatarul pe arborele care ii este atribuit.
Pentru ca el trebuie construit in aplicatie. La fiecare nod utilizatorul aplicatiei poate decide ce actiune sa se ia. Pe scurt am un email initial urmat de o conditie care poate sa fie de mai multe tipuri, iar pe fiecare ramura (“Da” sau “Nu”) poate exista cate o actiune care de asemenea poate sa fie de mai multe tipuri.
Nu comentez necesitatea (oarecum neobisnuita) unui arbore in aceasta aplicatie dar o varianta ar putea fi in format JSON iar ca suport se poate folosi o baza de date cu suport pentru JSON (SQlite,MySQL dar e mai greu sa cauti in structuri variabile) sau una NoSQL (Mongo) in care s-ar putea sa iti fie mai usor la cautare
@kilogrammer, asa cum am spus in postul initial, eram curios daca are cineva experienta cu asa ceva, ce varianta de implementare a ales. Nu e ceva exotic, astfel de flow-uri se construiesc frecvent in platforme de e-mail marketing.
@geosoft1, in JSON ma gandeam sa tin anumite setari ale fiecarui nod, nu intreg arborele.
Mi se pare ca te hazardezi sa obtii doar o solutie tehnica, desi din ce vad se incearca un design ceva mai arhitectural, ca sa poti primi raspunsuri bune. Faptul ca se numeste arbore de decizie nu implica deloc faptul ca vei reprezenta asa in memorie; in plus nu se preteaza la omnichannel, deci e deprecated rău (acum 12 ani faceam omnichannel). Poate fi afisat ca u arbore, UI-ul iar nu inseamna ca structura de date din spate e un arbore.
Intr-adevar, doar pentru cel care-l construieste trebuie sa arate ca un arbore, in baza de date nu e nevoie sa fie salvat in acest mod, dar ma gandeam ca ar fi mai “comod” asa.
Fa-ti o lista de lucruri de care ai nevoie la nivel de functionalitate. Descriere tip use-case, ca apoi sa poti valida prin teste automate diversele scenarii. Nu te baza ca vei putea sa refaci testarea manual de prea multe ori, e mult prea stufos.
Apoi ai doua optiuni: gasesti gata implementat, sau faci tu.
un tabel sql de forma de mai jos poate fi un inceput
actions
id
id_parent (id-ul actiunii parinte pentru afisare in UI)
action_name (ex: open_email)
value (ex: yes/no)
id_decision (id-ul actiunii care sa se intample mai departe)
Ce descrii tu aici îmi aduce aminte foarte mult de Drupal (views - mai nou parte din core, rules, workflow). În Drupal foarte multe funcționalități pot fi modificate/create din UI, inclusiv chestii de logică.
Ce a zis @tekkie e foarte adevărat: poate în UI se vrea a fi un arbore, dar în spate (cum e salvat) poate să fie orice altceva. Adaptezi în funcție de ce vrei tu.
Ce a zis @kleampa e un bun început. Eu unul nu aș încerca ceva fără parent_id la început (nu o să fie tot timpul arbore, dar cred că e mai simplu să configurezi acțiuni independente gen ITTT decât un arbore complet). Plus că tot arborele respectiv are un state, pe care nu ai descris cum trebuie salvat (pe adresă de email / campanie de emailuri / email trimis etc)
să zicem că fiecare nod decizional din așa numitul arbore are o structură de genul:
eveniment - când se activează (pot să fie activate de alte noduri și atunci ține rol de parent_id, sau eventuri de genul am primit confirmare că utilizatorul a deschis emailul, sau a trecut o periodă determinată de timp să nu am primit notificare cum că a deschis emailul)
condiții - chiar dacă au fost activate de către event, e posibil să nu facă nimic dacă nu sunt îndeplinite unele condiții
acțiuni: ce să se întâmple
la condiții trebuie să te gândești că la un moment dat o să ai nevoie de operatori logici (OR / AND) între condiții (poate nu de la început, dar o să vină probabil și inevitabil o să ajungi la recursivitate )
la acțiuni poți să ai mai multe acțiuni la fiecare event. o să-ți prindă bine dacă implementezi stocarea cu asta în minte, chiar dacă la început o să limitezi sistemul la o singură acțiune
Toate cele de mai sus (eveniment, condiții, acțiuni) pot fi abstractizate destul de fain, însă nu e o treabă simplă. Ca să nu ai bătăi de cap, încearcă să obții cât mai multe use case-uri astfel încât să acoperi cam tot ce se așteaptă de la sistem.
Use case-urile au fost definite, este destul de clar ce si cum trebuie sa se intample la nivel teoretic, dar am simplificat un pic in postare. Sunt la pasul la care trebuie scrisa documentatia tehnica/de implementare.
Initial si eu m-am gandit la o structura similara cu cea propusa de @kleampa, dar ulterior mi-am dat seama ca e mult mai complex totul Am in vedere toate cele mentionate cu privire la structura unui nod decizional, iar in ceea ce priveste state-ul, el trebuie salvat per recipient.
Uite-te pe implementarile in interfata la ITTT, e fix ce vrei tu sa faci. In spate tine-le ca records intr-o tabela (doua, trei in fc de ce ai nevoie). Te complici aiurea sa tii structura ca un arbore.
Don’t overcomplicate your life ==> Go with a JSON or string field on a table in your already existing relational DB. If you don’t have a relational DB, get one
E o structure mica pe care o accesezi mai mereu ca un intreg. Ma gandesc ca ai doua flow-uri mari: un editor in care adaugi noduri si editezi attribute, si altul in care actionezi pe baza decision tree-ului la un nou event. La ce volume ma gandesc ca sunt, nici macar un cache sau in-memory-storage nu-i nevoie in ambele situatii.
)
Am in vedere toate cele mentionate cu privire la structura unui nod decizional, iar in ceea ce priveste state-ul, el trebuie salvat per recipient.