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

Question

Avant-propos: Je n'ai pas d'expérience avec des moteurs de règles, les règles de construction, des règles de modélisation, la mise en œuvre des structures de données des règles, ou tout le reste. Par conséquent, je ne sais pas ce que je fais ou si ce que je tentais ci-dessous est tout à fait farfelu.

Je suis en train de comprendre comment stocker et traiter le scénario hypothétique suivant. Pour simplifier mon problème, dire que j'ai un type de jeu où un utilisateur achète un objet, où il pourrait y avoir 1000 des objets possibles, et les objets doivent être achetés dans une séquence spécifiée et seulement dans certains groupes. Par exemple, dire que je suis l'utilisateur et je veux acheter l'objet F. Avant que je puisse acheter F objet, je dois avoir l'objet précédemment acheté 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 la règle précise. Une première, puis F plus tard. Ou, B, C, puis F plus tard. Je ne suis pas inquiet en ce moment avec le laps de temps entre les achats, ou toute autre caractéristique de l'utilisateur, juste qu'ils sont la séquence correcte pour l'instant.

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?

Je l'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 tableaux:

 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 des chaînes excessive si possible :). Un objet pourrait avoir un nombre inconnu de précédents achats requis. extraits SQL ou psuedocode pour traiter les règles seraient appréciés. :)

Answer 1

Il semble que votre problème se décompose pour tester si une condition particulière est satisfaite.

Vous aurez des conditions composées. Donc, étant donné une table d'éléments:

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 signifie donc l'id est une clé à la table des éléments, et MEETS_CONDITION signifie que l'id est une clé à la table Conditions.

Ce ne vise pas à vous restreindre. Vous pouvez ajouter d'autres tables avec des quêtes ou que ce soit, et ajouter des verbes supplémentaires pour vous dire où regarder. Ou, il suffit de mettre des quêtes dans vos articles table quand vous les remplir, puis interpréter une quête complétée comme posséder un badge particulier. Ensuite, vous pouvez gérer à la fois des articles et des quêtes avec le même code.

Answer 2

Ceci est un problème très complexe que 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, des quêtes et des objets et des « statistiques » pour divers objets peuvent avoir des dépendances non relationnelles. Ce fil peut vous aider beaucoup .

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

Answer 3

Personnellement, je ferais cela dans le code, pas dans SQL. Chaque élément doit être sa propre classe qui implémente une interface (à savoir iItem). IItem aurait une méthode appelée OkToPurchase qui détermine si elle est OK pour acheter cet article. Pour ce faire, il utiliserait une ou plusieurs d'un ensemble de règles (à savoir HasPreviouslyPurchased (x), CurrentlyOwns (x), etc.) que vous pouvez construire.

La bonne chose est qu'il est facile d'étendre cette approche avec de nouvelles règles sans casser toute la logique existante.

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