논리 규칙을 저장할 적절한 데이터 구조 및 데이터베이스 스키마는 무엇입니까?

Question

머리말 : 나는 규칙 엔진, 건물 규칙, 모델링 규칙, 규칙을위한 데이터 구조 구현 또는 기타 등등에 대한 경험이 없다. 따라서, 나는 내가하고있는 일이나 내가 아래에서 시도한 것이 기초를 벗어난 방법인지 모릅니다.

나는 다음 가상 시나리오를 저장하고 처리하는 방법을 알아 내려고하고 있습니다. 내 문제를 단순화하려면 사용자가 가능한 물건을 1000 개가 될 수있는 물건을 구매하는 게임 유형이 있고 물건을 특정 순서대로 그리고 특정 그룹에서만 구매해야한다고 말한다. 예를 들어, 내가 사용자이고 F 객체를 구매하려고합니다. F 객체를 구입하려면 먼저 A 객체 (B AND C)를 구입해야합니다. 나는 F와 A를 동시에 살 수 없으며 F와 B, C도 살 수 없다. 규칙에 지정된 순서대로 있어야합니다. 첫째, F 다음. 또는 B, C를 먼저 누른 다음 F를 누릅니다. 나는 지금 구매에 걸리는 시간의 범위 나 사용자의 다른 특성에 대해서는 관심이 없다. 지금은 올바른 순서에 불과하다.

구매할 개체에 대한 규칙을 읽고 사용자의 이전 구매 내역과 비교할 수있는 수천 개의 개체에 대해이 정보를 저장하는 가장 좋은 방법은 무엇입니까?

나는 이것을 시도했지만 A OR (B AND C)과 같은 그룹을 구현하려고 노력 중이다.

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

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

그러나 당신이 결과를 통해 처리로 분명히 그룹화하지 않고, 잘못된 답변을 얻을 : 나는 이러한 테이블이 곳 데이터베이스에 규칙을 저장하고 싶습니다. 가능한 경우 과도한 문자열 구문 분석을 피하고 싶습니다. :) 하나의 객체는 이전에 요구 된 구매 횟수를 알 수 없습니다. SQL 또는 psuedocode 스 니펫이 규칙 처리에 도움이 될 것입니다. :)

Answer 1

귀하의 문제는 특정 조건이 충족되었는지 여부를 테스트하는 것으로 나빠집니다.

복합 조건이 적용됩니다. 그래서 항목의 테이블에 주어진 :

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

를 가능한 작업 테이블에 주어진 : 우리는 조건의 테이블을 구성

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

:

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

그래서 소유

는 ID가 의미 Items 테이블의 키이고 MEETS_CONDITION은 ID가 Conditions 테이블의 키임을 의미합니다.

이것은 귀하를 제한하려는 것이 아닙니다. 퀘스트 등으로 다른 테이블을 추가 할 수 있으며 추가 동사를 추가하여 어디서 볼 수 있는지 알려줍니다. 또는 완료 할 때 아이템 테이블에 퀘스트를 넣은 다음 완성 된 퀘스트를 특정 뱃지를 소유 한 것으로 해석하십시오. 그런 다음 동일한 코드로 항목과 퀘스트를 모두 처리 할 수 ​​있습니다.

Answer 2

이것은 답변 할 자격이없는 매우 복잡한 문제이지만 많은 참고 자료를 보았습니다. 근본적인 문제는 게임의 경우 다양한 객체에 대한 퀘스트 및 항목과 '통계'가 비 관계 종속성을 가질 수 있다는 것입니다. This thread may help you a lot.

주제에 관한 몇 권의 책을 들고 규칙 프로세서로 LUA를 사용하는 것이 좋습니다.

Answer 3

개인적으로 SQL에서는이 작업을 코드에서 수행합니다. 각 항목은 인터페이스를 구현하는 자체 클래스 여야합니다 (예 :IItem). IItem은 OkToPurchase라는 메서드를 사용하여 해당 항목을 구입할 수 있는지 여부를 결정합니다. 그렇게하기 위해 빌드 할 수있는 하나 이상의 규칙 모음 (예 : HasPreviouslyPurchased (x), CurrentlyOwns (x) 등)을 사용합니다.

좋은 점은 모든 기존 논리를 깨지 않으면 서 새로운 규칙으로이 접근법을 쉽게 확장 할 수 있다는 것입니다.

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

: 여기

어떤 의사입니다