2v2 खेल के लिए डेटाबेस संरचना

Question

मैं नियमित रूप से 12 दोस्तों के साथ एक 2v2 गेम खेलता हूं और मैं रैंकिंग सिस्टम बनाने के इरादे से खिलाड़ियों, टीमों, स्कोर और गेम का ट्रैक रखना चाहता हूं।

चूँकि हम नियमित रूप से टीमों को बदलते हैं, मैं टेबल के साथ आया हूं players, teamsऔर gamesजहां खेलों में दो टीम (टीम 1 और टीम 2) हैं और टीमों में दो खिलाड़ी (खिलाड़ी 1 और खिलाड़ी 2) शामिल हैं।

यह काफी समस्याओं का कारण बनता है - उदाहरण के लिए अगर मैं दो खिलाड़ियों को चुनता हूं (चलो उन्हें ए और बी कहते हैं ) एक साथ खेलने के लिए, मुझे यह देखना होगा कि क्या पहले से ही एक टीम मौजूद है जहां प्लेयर 1 ए और प्लेयर 2 बी या प्लेयर 1 बी और प्लेयर 2 है एक है।

स्तंभ gamesऔर तालिका और तालिका winsदोनों में मौजूद हैं - लेकिन यह इसलिए है क्योंकि मैं दोनों को देखना चाहता हूं कि खिलाड़ियों ने कितने गेम जीते हैं, लेकिन यह भी कि खिलाड़ी अलग-अलग टीमों में कितने संगत हैं (एक खिलाड़ी कितनी बार जीतता है एक और विशिष्ट खिलाड़ी)।playersteams

1. रैंकिंग स्कोरबोर्ड (मैं शायद एलो रेटिंग प्रणाली का उपयोग करने वाला हूं )
2. रेटिंग, जीत, खेल, हाल के खेल के आँकड़े, और किन खिलाड़ियों के साथ वह सबसे अधिक संगत है, के साथ हर खिलाड़ी के लिए एक आँकड़े पृष्ठ।

मुझे दृढ़ता से संदेह है कि इसका अधिकांश डेटाबेस सामान्यीकरण में कुछ सिद्धांतों का उल्लंघन करता है, और मुझे अपने डेटाबेस डिज़ाइन को कैसे लागू करना है, कुछ सुझाव पसंद आएंगे।

Comments

मुझे लगता है कि यह एक बहुत अच्छा सवाल है। प्रश्न में आरेखित आपकी वर्तमान DB संरचना को देखना पसंद करेंगे। लारवेल के स्कीमा बिल्डर को हर कोई नहीं जानता। उपयोग के मामलों को भी बेहतर तरीके से सुलझाया जा सकता है ताकि हम आपकी वास्तविक जरूरतों को समझ सकें।

— कैंडिड_ऑरेंज

बहुत बहुत धन्यवाद @CandiedOrange - मैंने DB संरचना आरेख को जोड़ा है, और अधिक उपयोग के मामलों को जोड़ देगा :)

— Daniel

अच्छा अद्यतन। क्या मैं यह मानने में सही रहूंगा कि प्रत्येक खिलाड़ी एक समय में केवल एक टीम में होगा और एक समय में केवल एक खेल में? इसके अलावा, खिलाड़ी उस टीम के लिए जानकारी को रीसेट किए बिना पुरानी टीमों में छोड़ देते हैं और वापस लौट जाते हैं?

— कैंडिड_ऑरेंज

@CandiedOrange मूल रूप से जब हम एक गेम खेलना चाहते हैं तो हम 4 खिलाड़ियों (कुल 12 खिलाड़ियों में से) को ढूंढते हैं और बेतरतीब ढंग से उन्हें टीम में शामिल करते हैं 2.

— डैनियल

मैं नहीं बता सकता कि अगर हाँ या नहीं था। मैं यह समझने की कोशिश कर रहा हूं कि समय आपके डिजाइन पर क्या प्रभाव डालता है।

— कैंडिड_ऑरेंज

Answer 1

दो मुद्दे हैं जो मैं आपके वर्तमान स्कीमा के साथ देखता हूं, एक यह है कि तालिका में दो फ़ील्ड्स की जांच करने का मुद्दा यह निर्धारित करने के लिए है कि क्या एक यौगिक कुंजी प्रभावी रूप से एक डुप्लिकेट है, और, कुछ समग्र डेटा अलग-अलग तालिकाओं में अलग-अलग रोल किए गए हैं। संस्थाएं (जीत, विशेष रूप से, लेकिन संभावित रूप से खिलाड़ी की रेटिंग भी)।

पहले मुद्दे के लिए, डीबी ट्रिक्स या तो नहीं हैं / कंपाउंड कुंजी के किसी भी क्षेत्र को उस तरीके से व्यवहार किया जाए जिसकी आप तलाश कर रहे हैं, लेकिन यदि आपका डीबी इसका समर्थन करता है, तो आप getPlayerTeams(player_id)इनकैप्सुलेट करने के लिए एक फ़ंक्शन बना सकते हैं पूछताछ।

(आप सॉर्ट किए गए खिलाड़ी आईडी के हैश के रूप में गणना की गई team_thumbprint के साथ एक दृश्य भी बना सकते हैं, ताकि एक ही दो लोगों के किसी भी कॉम्बो का परिणाम हमेशा एक ही थंबप्रिंट में हो, लेकिन यह यहां बहुत अधिक हो सकता है)।

जहां तक ​​सामान्यीकरण है, team_resultकिसी दिए गए टीम के सभी परिणामों को ट्रैक करने के लिए तालिका का उपयोग करके परिणामों से संस्थाओं को अलग करने पर विचार करें । एक player_rating_histखिलाड़ी के लिए सभी रेटिंग परिवर्तन वाले एक तालिका के लिए थोड़ा और अति सामान्यीकरण भी कॉल करेगा । उनकी वर्तमान रेटिंग बस सबसे हाल की तारीख के साथ एक है। एक खिलाड़ी दृश्य भी आसान क्वेरी के लिए सबसे हाल के मूल्य को शामिल करने के लिए इस्तेमाल किया जा सकता है।

प्रस्तावित स्कीमा (क्षमा करें कोई आरेख):

player
    id
    name
    created_on
    updated_on

player_rating_hist
    player_id (FK)
    rating
    rating_date

team
    id
    player1_id (FK)
    player2_id (FK)
    created_on
    updated_on

game
    id
    team1_id (FK)
    team2_id (FK)

team_game
    team_id (FK)
    game_id (FK)
    result
    score
    rating_change

team_rating_hist
    team_id (FK)
    rating
    rating_date

क्वेरी:

--Results for the game, should only ever be two rows for any given game
SELECT * FROM team_game WHERE game_id = 101

--All results for a team
SELECT * FROM team_game WHERE team_id = 123456 

यह संरचना "आधार" संस्थाओं (खिलाड़ियों और टीमों) को "सामग्री" से अलग करने की अनुमति देती है जो समय के साथ चल रही प्रणाली के परिणामस्वरूप होती है, और इसका मतलब है कि आप वर्तमान रेटिंग के साथ बेस तालिकाओं में से एक को लगातार अपडेट नहीं कर रहे हैं, # जीत, आदि। जो व्युत्पन्न मूल्य हैं और उन्हें सबसे हाल की रेटिंग, औसत रेटिंग, COUNTजीत या हार, आदि के द्वारा प्राप्त किया जाना चाहिए । यदि सिस्टम पर्याप्त बड़ा हो गया है, तो आप इस तरह के डेटा को अलग "वेयरहाउस" में निकालने पर विचार कर सकते हैं। (भले ही यह एक ही DB में तालिकाओं का एक अलग सेट था) आसान विश्लेषण के लिए।