ما هو بنية البيانات المناسبة ومخطط قواعد البيانات لتخزين قواعد المنطق؟

Question

مقدمة: ليس لدي خبرة في محركات القواعد أو قواعد البناء أو قواعد النمذجة أو تنفيذ هياكل البيانات للقواعد أو Whatnot. لذلك، لا أعرف ما أفعله أو إذا حاولت ما أذهب إليه أدناه.

أحاول معرفة كيفية تخزين ومعالجة السيناريو الافتراضي التالي. لتبسيط مشكلتي، قل أن لدي نوع من اللعبة حيث يقوم المستخدم بشراء كائن، حيث يمكن أن يكون هناك 1000 من الكائنات الممكنة، ويجب شراء الكائنات في تسلسل محدد وفقط في مجموعات معينة فقط. على سبيل المثال، أقول أنا المستخدم وأريد شراء كائن F. قبل أن أتمكن من شراء كائن F، يجب أن أكون قد اشتريت في السابق كائن A أو (B و C). لا أستطيع شراء F و A في نفس الوقت، ولا F و B، C. يجب أن يكونوا في التسلسل تحدد القاعدة. أولا، ثم F في وقت لاحق. أو، ب، ج أولا، ثم F في وقت لاحق. أنا لا قلق الآن مع فترة الزمن بين المشتريات، أو أي خصائص أخرى للمستخدم، فقط أنها التسلسل الصحيح الآن.

ما هي أفضل طريقة لتخزين هذه المعلومات لآلاف الكائنات المحتملة التي تسمح لي بالقراءة في قواعد الكائن الذي يتم شراؤه، ثم التحقق من ذلك ضد سجل الشراء السابق للمستخدم؟

لقد حاولت ذلك، لكنني عالق في محاولة تنفيذ التجمعات مثل O أو (B و C). أرغب في تخزين القواعد في قاعدة بيانات حيث لدي هذه الجداول:

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

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

ولكن من الواضح أنك تعالج من خلال النتائج، دون التجميع، تحصل على إجابة خاطئة. أود تجنب تحليل السلسلة المفرط إذا كان ذلك ممكنا :). يمكن أن يكون لك كائن واحد عدد غير معروف من المشتريات السابقة المطلوبة. مقتضى SQL أو PSUDocode لمعالجة القواعد موضع تقدير موضع تقدير. :)

Answer 1

يبدو أن مشكلتك تنهار للاختبار ما إذا كانت حالة معينة راضية.

سيكون لديك ظروف مركبة. لذلك بالنظر إلى جدول العناصر:

id_item الوصف ---------------------- 1 a 2 b 3 c 4 f

وحدد جدول الإجراءات الممكنة:

Id_action Verid Inditid Codeid ---------------------------------------- 1 شراء 4 1

نبني جدول الظروف:

ID_CONDITITITITITITITITITITITIT IONJECTA_ID Boolean Verbb ObjectB_ID ---------------------------------------------- ------------------------- 1 تمتلك 1 أو meets_condition 2 2 تمتلك 2 وتمتلك 3

يمتلك ذلك يعني أن المعرف هو مفتاح جدول العناصر، ويعني MEETS_CONDITION أن المعرف هو مفتاح جدول الحالات.

هذا لا يعني أن تقيدك. يمكنك إضافة طاولات أخرى مع المهام أو أيا كان، وإضافة أفعال إضافية لإخبارك أين تبدو. أو، فقط ضع المهام في جدول البنود الخاصة بك عند إكمالها، ثم قم بتفسير السعي المكتمل كما يمتلك شارة معينة. ثم يمكنك التعامل مع كل من العناصر والمهام مع نفس الرمز.

Answer 2

هذه مشكلة معقدة للغاية وأنا غير مؤهل للإجابة، لكنني رأيت الكثير من الإشارات إلى. المشكلة الأساسية هي أنه بالنسبة للألعاب والمهام والعناصر "إحصائيات" للأشياء المختلفة يمكن أن تحتوي على تبعيات غير علنية. هذا الموضوع قد يساعدك كثيرا.

قد ترغب في التقاط مكتبة زوجين حول الموضوع، وانظر إلى استخدام LUA كمعالج قواعد.

Answer 3

شخصيا سأفعل هذا في التعليمات البرمجية، وليس في SQL. يجب أن يكون كل عنصر من الفئة الخاصة به في تطبيق واجهة (أي IITEM). سيكون لدى IITEM طريقة تسمى OKTOPurchase التي من شأنها تحديد ما إذا كان على ما يرام لشراء هذا البند. للقيام بذلك، سيستخدم واحدة أو أكثر من مجموعة من القواعد (أي Haspriviousingurchased (x)، في الياضاف (X)، وما إلى ذلك) التي يمكنك بناءها.

الشيء الجميل هو أنه من السهل تمديد هذا النهج بقواعد جديدة دون كسر جميع المنطق الحالي.

إليك بعض pseudocode:

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