Qu'est-ce qu'une structure de données et un schéma de base de données appropriés pour stocker les règles logiques?

Question

Préface: Je n'ai aucune expérience avec les moteurs de règles, les règles de construction, les règles de modélisation, l'implémentation de structures de données pour les règles, ou quoi que ce soit d'autre. Par conséquent, je ne sais pas ce que je fais ou si ce que j'ai essayé ci-dessous est loin de la base.

J'essaie de comprendre comment stocker et traiter le scénario hypothétique suivant. Pour simplifier mon problème, disons que j'ai un type de jeu où un utilisateur achète un objet, où il pourrait y avoir des milliers d'objets possibles, et les objets doivent être achetés dans une séquence spécifiée et seulement dans certains groupes. Par exemple, disons que je suis l'utilisateur et que je veux acheter l'objet F. Avant de pouvoir acheter l'objet F, je dois avoir préalablement acheté l'objet A OU (B et C). Je ne peux pas acheter F et A en même temps, ni F et B, C. Ils doivent être dans la séquence spécifiée par la règle. Une première, puis F plus tard. Ou, B, C d'abord, puis F plus tard. Je ne suis pas concerné en ce moment avec l'intervalle de temps entre les achats, ou d'autres caractéristiques de l'utilisateur, juste qu'ils sont la séquence correcte pour le moment.

Quelle est la meilleure façon de stocker ces informations pour potentiellement des milliers d'objets qui me permet de lire dans les règles de l'objet acheté, puis le vérifier contre les antécédents d'achat de l'utilisateur?

J'ai essayé, mais je suis coincé à essayer de mettre en œuvre les groupements tels que A OU (B et C). Je voudrais stocker les règles dans une base de données où j'ai ces tables:

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

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

Mais il est évident que vous traitez à travers les résultats, sans le groupement, vous obtenez la mauvaise réponse. Je voudrais éviter l'analyse excessive des chaînes si possible :). Un objet peut avoir un nombre inconnu d'achats requis précédents. Des extraits SQL ou psuedocode pour le traitement des règles seraient appréciés. :)

Answer 1

Il semble que votre problème se résume à tester si une condition particulière a été satisfaite.

Vous aurez des conditions composées. donc donné une table des objets:

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

et donné une table d'actions possibles:

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

Nous construisons une table de conditions:

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

possède donc signifie que l'id est une clé de la table Items, et MEETS_CONDITION signifie que l'ID est une clé de la table Conditions.

Ceci n'est pas destiné à vous restreindre. Vous pouvez ajouter d'autres tables avec des quêtes ou autres, et ajouter des verbes supplémentaires pour vous dire où chercher. Vous pouvez également placer des quêtes dans votre table Articles lorsque vous les avez terminées, puis interpréter une quête terminée comme possédant un badge particulier. Ensuite, vous pouvez gérer les deux objets et les quêtes avec le même code.

Answer 2

Ceci est un problème très complexe auquel je ne suis pas qualifié pour répondre, mais j'ai vu beaucoup de références à. Le problème fondamental est que pour les jeux, les quêtes et les objets et les «stats» pour divers objets peuvent avoir des dépendances non-relationnelles. This thread may help you a lot.

Vous pouvez ramasser quelques livres sur le sujet, et regarder dans LUA comme processeur de règles.

Answer 3

Personnellement, je le ferais dans le code, pas en SQL. Chaque élément doit être sa propre classe implémentant une interface (c.-à-d.IItem). IItem aurait une méthode appelée OkToPurchase qui déterminerait si c'est OK pour acheter cet article. Pour ce faire, il utilisera un ou plusieurs ensembles de règles (c'est-à-dire HasPreviouslyPurchased (x), CurrentlyOwns (x), etc.) que vous pouvez créer. La bonne chose est qu'il est facile d'étendre cette approche avec de nouvelles règles sans casser toute la logique existante.

Voici quelques pseudo-code:

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) 
}