डाटाबेस गेम मैसेजिंग स्कीमा

Question

मैं अपने गेम में मैसेजिंग सिस्टम के लिए बैक एंड के रूप में डेटाबेस का उपयोग करने की कोशिश कर रहा हूं (इंस्टेंट मैसेजिंग की तरह)। मैं प्राप्त संदेश भेजने के लिए एक स्थानीय डेटाबेस का उपयोग कर रहा हूं और उन्हें भेजने के लिए अपने सर्वर पर एक डेटाबेस।

उपयोगकर्ता:: (varchar)
DISPLAYNAME (varchar)
currentGames (varchar)

संदेश
प्रयोक्ता नाम: यहाँ टेबल है कि मैं का उपयोग कर रहा हैं
इस (varchar)
रिसीवर (varchar)
संदेश (varchar)
टाइमस्टैम्प (int)

मेरे pla n यह है कि जब कोई उपयोगकर्ता संदेश भेजता है, तो मैं पहले संदेश को अपने स्थानीय डेटाबेस में संग्रहीत करता हूं और फिर संदेश को सर्वर पर भेजता हूं।

जब कोई उपयोगकर्ता यह देखने के लिए जांच करता है कि कोई नया संदेश (मतदान) है, तो उसे पहले अपने स्थानीय डेटाबेस से नवीनतम टाइमस्टैम्प मिल जाता है और उस समय के बाद भेजे गए सभी संदेशों के लिए ऑनलाइन डेटाबेस से पूछताछ करने के लिए इसका उपयोग करता है। प्राप्त सभी संदेश डेटाबेस से हटा दिए जाते हैं।

क्या मैं ऐसा करने में कुछ गलत कर रहा हूं? मैं सबसे खराब के लिए तैयार करने की कोशिश कर रहा हूं, और मुझे नहीं पता कि इस तरह की योजना कैसे स्केल करेगी। मैं "उपयोगकर्ता" तालिका के लिए एक अद्वितीय आईडी का उपयोग नहीं कर रहा हूं और मुझे लगता है कि मुझे चाहिए। चूंकि मेरा डेटाबेस अनुभव सीमित है, इसलिए मैं अद्वितीय ऑटो-वृद्धि आईडी के महत्व को पूरी तरह समझ नहीं पा रहा हूं या यह मेरी सहायता कैसे करेगा। किसी भी सलाह/आलोचना की सराहना की जाएगी।

Answer 1

चूंकि ज्यादातर गेमर टैग क्षणिक होते हैं और आप शायद एक गेमर के आईडी (निजी) और उनके उपयोगकर्ता नाम (सार्वजनिक, कम से कम दोस्तों के लिए) के बीच फ़र्क करना तो आप इस तरह एक स्थानीय डिजाइन हैं:

FRIEND -- The local user's own tag should go in here too. 
(user_id 
, current_gamer_tag 
, last_update_timestamp 
) 

GAME 
(game_id 
, game_name -- No timestamp here because the name doesn't change? 
) 

MESSAGE 
(message_id -- If you make this a GUID you can use it for synching with the server. 
, sending_user_id -- FK to FRIEND 
, receiving_user_id -- Also FK to FRIEND 
, timestamp 
, content 
) 

इसमें स्थानीय रूप से आउटगोइंग और इनकमिंग संदेश दोनों हैं और संदेश को गेमर पर टैग करने की अनुमति देता है जबकि साथ ही सर्वर के साथ सिंक्रनाइज़ करना आसान होता है। वैसे, यदि आप तीन या अधिक-तरह के गेम खेलने के लिए प्राप्तकर्ताओं की एक सूची वाले प्राप्तकर्ता_user_id को उप-तालिका में बदलना भी विचार कर सकते हैं।

कई कारणों से अद्वितीय आईडी का उपयोग करना महत्वपूर्ण है। सबसे महत्वपूर्ण यह है कि यह आपको अपने गेमर टैग को संशोधित करने की अनुमति देता है और आपको संदेश प्रदर्शित करने में अपने खिलाड़ियों के उपयोगकर्ता आईडी प्रकट करने से रोकता है।यहाँ एक अंतरिक्ष की बचत भी है क्योंकि एक पूर्णांक, यहां तक ​​कि एक बड़ा गेम एक गेमर टैग से छोटा है। यह स्केलेबिलिटी के लिए बेहतर है। संदेश आईडी के लिए बढ़ते पूर्णांक के बजाय GUID का उपयोग करना मतलब है कि आपके पास अपने सर्वर की संदेश तालिका पर "हॉट-स्पॉट डालें" नहीं होगा, जो तब तक बेहतर प्रदर्शन करेगा जब तक आपके सर्वर संदेश तालिका में पर्याप्त खाली स्थान नहीं बनाया गया हो । साथ ही, संदेश आईडी क्लाइंट के अंत में जेनरेट की जा सकती है और आप बहुत आश्वस्त हो सकते हैं कि जब संदेश सर्वर पर आते हैं तो कोई महत्वपूर्ण टक्कर नहीं होगी।

Answer 2

यहां मेरी ओर देखो। यह सिर्फ मैं यह कैसे करूंगा ....

यह सब निर्भर करता है कि आपका सिस्टम कैसे काम करता है। यदि प्रत्येक उपयोगकर्ता नाम को एक बार उपयोग करने की अनुमति दें और उपयोगकर्ता को इसे बदलने की अनुमति न दें, तो तार्किक रूप से आपको किसी आईडी का उपयोग करने की आवश्यकता नहीं होगी। व्यक्तिगत रूप से, मैं अपने उपयोगकर्ता डेटाबेस के लिए एक auto_incremented आईडी का उपयोग करता हूं। अगर मैं आप थे, तो मैं एक आईडी का उपयोग करता हूं, यह सबकुछ सरल करेगा। यदि आप उपयोगकर्ता के आईडी खेल जानकारी को भेजने के साथ ही करना होगा जब ऑनलाइन डेटाबेस को प्रस्तुत

Friend's database: 
USER_ID USERNAME 

Game's database: 
GAME_ID USER_PLAYING_ID 

Messages database: 
TO_USER TIMESTAMP GAME_ID 

तो:

probally स्थानीय डेटाबेस पर आप कुछ इस तरह की आवश्यकता होगी।

फिर से, मैं इसे कैसे करूँगा। बाकी सब कुछ के अलावा, ऐसा लगता है जैसे आप जानते हैं कि आप क्या कर रहे हैं।