Cấu trúc dữ liệu và lược đồ cơ sở dữ liệu thích hợp để lưu trữ các quy tắc logic là gì?

Question

Lời nói đầu: Tôi không có kinh nghiệm với các công cụ quy tắc, quy tắc xây dựng, quy tắc mô hình hóa, triển khai cấu trúc dữ liệu cho các quy tắc hoặc điều gì đó. Vì vậy, tôi không biết tôi đang làm gì hoặc nếu những gì tôi cố gắng dưới đây là cách rời khỏi cơ sở.

Tôi đang cố gắng tìm ra cách lưu trữ và xử lý kịch bản giả định sau đây. Để đơn giản hóa vấn đề của tôi, hãy nói rằng tôi có một loại trò chơi mà người dùng mua một đối tượng, nơi có thể có 1000 đối tượng có thể và đối tượng phải được mua trong một chuỗi được chỉ định và chỉ trong một số nhóm nhất định. Ví dụ: giả sử tôi là người dùng và tôi muốn mua đối tượng F. Trước khi tôi có thể mua đối tượng F, trước đây tôi phải mua đối tượng A OR (B VÀ C). Tôi không thể mua F và A cùng lúc, cũng như F và B, C. Chúng phải nằm trong trình tự quy tắc chỉ định. Đầu tiên, sau đó là F sau. Hoặc, B, C trước, sau đó là F sau. Tôi không quan tâm ngay bây giờ với khoảng thời gian giữa các lần mua hàng hoặc bất kỳ đặc điểm nào khác của người dùng, chỉ là chúng là trình tự chính xác cho đến bây giờ.

Cách tốt nhất để lưu trữ thông tin này cho hàng nghìn đối tượng có thể cho phép tôi đọc trong quy tắc cho đối tượng đang được mua và sau đó kiểm tra đối với lịch sử mua trước đó của người dùng?

Tôi đã thử điều này, nhưng tôi bị kẹt khi cố gắng triển khai các nhóm như A OR (B VÀ C). Tôi muốn lưu trữ các quy tắc trong cơ sở dữ liệu nơi tôi có các bảng này:

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

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

Nhưng rõ ràng là khi bạn xử lý thông qua kết quả mà không có nhóm, bạn sẽ nhận được câu trả lời sai. Tôi muốn tránh phân tích chuỗi quá mức nếu có thể :). Một đối tượng có thể có số lượng không xác định các lần mua hàng bắt buộc trước đó. Các đoạn mã SQL hoặc psuedocode để xử lý các quy tắc sẽ được đánh giá cao. :)

Answer 1

Có vẻ như vấn đề của bạn bị hỏng để kiểm tra xem một điều kiện cụ thể có được đáp ứng hay không.

Bạn sẽ có điều kiện hỗn hợp. Vì vậy, cho một bảng các mặt hàng:

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

và đưa ra một bảng của các hành động có thể:

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

Chúng tôi xây dựng một bảng điều kiện:

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

Vì vậy SỞ HỮU nghĩa id là một khóa vào bảng Items và MEETS_CONDITION có nghĩa là id là khóa cho bảng Conditions.

Điều này không có nghĩa là hạn chế bạn. Bạn có thể thêm các bảng khác với nhiệm vụ hoặc bất cứ điều gì, và thêm động từ bổ sung để cho bạn biết nơi để tìm. Hoặc, chỉ cần đặt các nhiệm vụ vào bảng Mục của bạn khi bạn hoàn thành chúng và sau đó diễn giải một nhiệm vụ hoàn thành khi sở hữu một huy hiệu cụ thể. Sau đó, bạn có thể xử lý cả các mục và nhiệm vụ với cùng một mã.

Answer 2

Đây là một vấn đề rất phức tạp mà tôi không đủ điều kiện để trả lời, nhưng tôi đã thấy rất nhiều tài liệu tham khảo. Vấn đề cơ bản là đối với trò chơi, nhiệm vụ và vật phẩm và "số liệu thống kê" cho các đối tượng khác nhau có thể có sự phụ thuộc không quan hệ. This thread may help you a lot.

Bạn có thể muốn chọn một vài cuốn sách về chủ đề này và xem xét sử dụng LUA làm bộ xử lý quy tắc.

Answer 3

Cá nhân tôi sẽ làm điều này trong mã, không phải trong SQL. Mỗi mục phải là lớp riêng của nó khi triển khai giao diện (tức làIItem). IItem sẽ có một phương thức gọi là OkToPurchase để xác định xem có thể mua mặt hàng đó hay không. Để làm điều đó, nó sẽ sử dụng một hoặc nhiều tập hợp các quy tắc (ví dụ: HasPreviouslyPurchased (x), CurrentlyOwns (x), v.v.) mà bạn có thể tạo.

Điều thú vị là dễ dàng mở rộng phương pháp này với các quy tắc mới mà không vi phạm tất cả logic hiện có.

Dưới đây là một số mã giả:

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