Come creare uno schema db per "se questo allora ... elseif ... elseif ..." e così via?

È possibile implementare una macchina a stati nel database salvando ogni passaggio e relativo link

es:

table state
    id
    name

table link
    id
    stateId -- start
    nextStateId -- agreed_to_T&Cs
    question -- do you agree to the T&Cs
    condition -- A = yes

Il problema arriva davvero nel codificare le domande. Devi costruire dinamicamente l'interfaccia utente per i diversi tipi, drop down, checkbox, testo, numero ecc. E valutare la condizione rispetto alla risposta e possibilmente altro stato.

Non è impossibile, ma alla fine si finisce per inventare una nuova lingua.

L'ho già fatto con un documento di stato XML, che accumuli con tutte le tue risposte e le condizioni XPath. Quale puoi valutare rispetto allo stato doc e ottenere un risultato vero / falso.

Ma non raccomanderei l'approccio. È più facile a lungo termine eseguire l'hardcode della logica e semplicemente modificare e ricompilare quando sono necessarie modifiche.

Il database deve essere utilizzato per memorizzare le soglie e le configurazioni che verranno utilizzate dalla logica decisionale nel codice, ad es. "Le entrate degli utenti sono maggiori di X, suggerisci il nostro prodotto Premium" X sarà nel DB, ma il codice che controlla se Utente.Income > X dovrebbe essere nel tuo linguaggio C # / Java / altro tipo strong. Per questo non hai bisogno di altro che tabelle come

Create Table IntSettings(
    name varchar(100) not null,
    value int not null
).

Questa dichiarazione della tabella "tipo strong" evita equivoci come un altro programmatore che tenta di inserire "$ 1000000" per un'impostazione di prezzo perché ritengono di dover fornire la valuta per qualsiasi motivo. Questo fraintendimento potrebbe causare l'esplosione di parte inattesa del codice durante l'analisi delle impostazioni.

Un'altra cosa che puoi memorizzare nel tuo DB è testo di domanda / opzione e le loro traduzioni. Sarebbe come l'altra tabella delle impostazioni, tranne le colonne per il paese / regione.

Il database non dovrebbe codificare cose come le domande poste all'utente, quale schermata andare a quella successiva ecc. perché hanno il loro posto nella tua architettura.

L'unico vantaggio di questo processo decisionale nel tuo schema è che puoi apportare modifiche ad hoc in risposta ai bug. Ma hai anche maggiori probabilità di commettere errori facendo tutto in SQL.

Se ti ritrovi a dover cambiare rapidamente l'interfaccia utente (e non riuscire ad aspettare la pubblicazione di un codice) dovresti migliorare la tua pipeline di distribuzione e anche chiedere di avere una buona immagine della progettazione dell'interfaccia utente, della logica aziendale e dei requisiti .

Se il numero di scelte è basso, puoi provare a utilizzare una tabella delle decisioni . Questa è una tabella di tutte le combinazioni booleane delle scelte che i tuoi utenti possono fare. Ad esempio, per 3 scelte, può apparire come segue:

choice 1|choice 2|choice 3|action
--------+--------+--------+-------
False   |False   |False   |DoFoo1
False   |False   |True    |DoFoo2
False   |True    |False   |DoFoo3
False   |True    |True    |DoFoo4
True    |False   |False   |DoFoo5
...

Naturalmente, in realtà la tabella potrebbe apparire diversa, le scelte potrebbero non essere solo "vere" o "false", e forse non si verificano molte combinazioni possibili (il che risulterebbe in una tabella sparsa).

Il salvataggio di una tabella di decisioni simile in un database non è particolarmente difficile. Probabilmente avrai bisogno di avere il numero di possibili opzioni da estendere in fase di esecuzione. Quindi potresti utilizzare uno schema DB con 3 tabelle ( ChoiceType per le n scelte possibili, Action per le possibili azioni e le scelte effettive in una tabella di link (forse chiamata Choice ) tra Action e ChoiceType ).

Naturalmente, questa soluzione funzionerà solo per un certo grado di complessità, se le dipendenze tra le diverse scelte e le azioni ("esperienze utente") diventano troppo complesse, qualcosa di diverso come una macchina a stati (come menzionato nei commenti ) potrebbe essere più adatto.

Hai già le basi giù. Probabilmente hai bisogno di un'entità per "passo" e un'entità per "condizione", in cui una condizione collega un passaggio a un altro. Come è rappresentato più concretamente questo è impossibile dire senza ulteriori dettagli su ciò che i passaggi e le condizioni effettivamente rappresentano nel codice. Per esempio. sono le condizioni input utente o espressioni di codice? Cosa succede nei passaggi? L'albero decisionale viene eseguito in un colpo solo o è necessario memorizzare lo stato come in "utente X è attualmente al passo B" nel database? Cosa succede alla fine del brunch?

Se assumiamo che ogni "condizione" è solo una domanda si / no presentata per l'utente, allora è piuttosto facile.

Step
====
Id (PK)

Condition
=========
Question (text)
Priority (number)
ForStepId (FK to Step)
ToStepId (FK to Step)

Se l'utente è al passo X, viene presentata la prima domanda con ForStepID = X. Se la risposta è sì, vai al passo indicato con ToStepId. Altrimenti presenti la prossima domanda per il passo X.

Penso che JaccquesB sia quasi arrivato.

Inizia a disegnare i tuoi stati e le transizioni su carta, indica come nodi e passaggi (= transizioni) come linee che li connettono. Scrivi le condizioni oltre le linee del passo. Nota che un passo ha una direzione, potrebbero esserci due diversi passaggi che collegano due stati qualsiasi. Un passo ha un da e uno a stato.

Quindi hai utenti, stati, passaggi e condizioni. Questo è il tuo modello:

User <<---> State 2--->> Step <--->> Condition

Le condizioni potrebbero non essere tutte riparate e potrebbero dipendere anche da alcune proprietà dell'utente. Sarebbe la logica della tua app gestibile.