Che cos'è una struttura dati appropriata e uno schema di database per memorizzare le regole logiche?

Question

Prefazione: non ho esperienza con motori di regole, regole di costruzione, regole di modellazione, implementazione di strutture di dati per regole o quant'altro. Pertanto, non so cosa sto facendo o se quello che ho tentato di seguito è completamente fuori base.

Sto cercando di capire come memorizzare ed elaborare il seguente scenario ipotetico. Per semplificare il mio problema, diciamo che ho un tipo di gioco in cui un utente acquista un oggetto, dove potrebbero esserci migliaia di oggetti possibili, e gli oggetti devono essere acquistati in una sequenza specifica e solo in determinati gruppi. Ad esempio, supponiamo che io sia l'utente e desidero acquistare l'oggetto F. Prima di poter acquistare l'oggetto F, è necessario aver acquistato in precedenza l'oggetto A OR (B AND C). Non posso comprare F e A allo stesso tempo, né F e B, C. Devono essere nella sequenza specificata dalla regola. Un primo, poi F dopo. O, B, C prima, poi F dopo. Al momento non mi interessa l'intervallo di tempo tra gli acquisti o qualsiasi altra caratteristica dell'utente, solo che per ora sono la sequenza corretta.

Qual è il modo migliore per archiviare queste informazioni per potenzialmente migliaia di oggetti che mi consentono di leggere le regole per l'oggetto acquistato e quindi controllarlo rispetto alla cronologia acquisti precedente dell'utente?

Ho tentato di farlo, ma sono bloccato nel tentativo di implementare i raggruppamenti come A OR (B AND C). Vorrei memorizzare le regole in un database dove ho queste tabelle:

Objects 
    (ID(int),Description(char)) 

ObjectPurchRules 
    (ObjectID(int),ReqirementObjectID(int),OperatorRule(char),Sequence(int)) 

Ma ovviamente, come si elabora attraverso i risultati, senza il raggruppamento, si ottiene la risposta sbagliata. Vorrei evitare un'eccessiva analisi delle stringhe, se possibile :). Un oggetto potrebbe avere un numero sconosciuto di acquisti precedenti richiesti. Snippet SQL o psuedocode per l'elaborazione delle regole sarebbero apprezzati. :)

Answer 1

Sembra che il problema si interrompa per verificare se una particolare condizione è stata soddisfatta.

Avrete condizioni composte. Quindi dato un tavolo gli oggetti:

 
ID_Item Description 
---------------------- 
1   A   
2   B   
3   C   
4   F   

e dato un tavolo di possibili azioni:

 
ID_Action VerbID ItemID ConditionID 
---------------------------------------- 
1   BUY  4   1 

Costruiamo una tabella di condizioni:

 
ID_Condition VerbA ObjectA_ID Boolean VerbB   ObjectB_ID 
--------------------------------------------------------------------- 
1    OWNS 1   OR  MEETS_CONDITION 2 
2    OWNS 2   AND  OWNS    3 

Così POSSIEDE significa che l'id è una chiave per la tabella degli articoli e MEETS_CONDITION significa che l'id è una chiave per la tabella delle condizioni.

Questo non ha lo scopo di limitare l'utente. Puoi aggiungere altri tavoli con quest o qualsiasi altra cosa, e aggiungere verbi extra per dirti dove cercare. Oppure, metti le quest nella tabella Oggetti quando le completi, e poi interpreti una missione completata come possedere un particolare badge. Quindi puoi gestire entrambi gli oggetti e le missioni con lo stesso codice.

Answer 2

Questo è un problema molto complesso a cui non sono qualificato per rispondere, ma ho visto molti riferimenti a. Il problema fondamentale è che per i giochi, le missioni e gli oggetti e le "statistiche" per vari oggetti possono avere dipendenze non relazionali. This thread may help you a lot.

Si potrebbe desiderare di raccogliere un paio di libri sull'argomento e esaminare l'utilizzo di LUA come processore di regole.

Answer 3

Personalmente lo farei nel codice, non in SQL. Ogni articolo dovrebbe essere una classe propria che implementa un'interfaccia (ad es.IItem). IItem avrebbe un metodo chiamato OkToPurchase che determinerebbe se è OK acquistare quell'elemento. Per farlo, usa una o più raccolte di regole (cioè HasPreviouslyPurchased (x), CurrentOwns (x), ecc.) Che puoi costruire.

La cosa bella è che è facile estendere questo approccio con nuove regole senza rompere tutta la logica esistente.

Ecco alcuni pseudocodice:

bool OkToPurchase() 
{ 
    if(HasPreviouslyPurchased('x') && !CurrentlyOwns('y')) 
     return true; 
    else 
     return false; 
} 

bool HasPreviouslyPurchased(item) 
{ 
    return purchases.contains(item) 
} 

bool CurrentlyOwns(item) 
{ 
    return user.Items.contains(item) 
}