एक संबंधपरक डेटाबेस के भीतर प्रयोग करने योग्य सूची / वस्तु / वस्तुओं (जैसे कतना) के लिए कई "उपयोग" (जैसे हथियार) को कैसे मॉडल करें


10

इसलिए मैं www.ninjawars.net पर आइटम्स के उपयोग का विस्तार करने पर काम कर रहा हूं , और मुझे यकीन नहीं है कि जिस रिलेशनल डेटाबेस का हम उपयोग करते हैं, उसमें लचीलेपन का प्रतिनिधित्व कैसे करें।

मैं गलत पेड़ को भौंक सकता हूं, इसलिए अन्य दिशाओं में सुझाव देने के लिए स्वतंत्र महसूस करता हूं, लेकिन वर्तमान में मैं सोच रहा हूं कि प्रत्येक आइटम में "टैग" होना चाहिए।

उदाहरण के लिए, एक कटाना वर्तमान में "आइटम" डेटाबेस में एक पंक्ति है। इसे एक हथियार, और एक धारणीय चीज़ बनाने के लिए, मैं सोच रहा था कि मेरे पास "लक्षण" का एक डेटाबेस होगा, और एक आइटम_टाइट्स टेबल जो बस उनके बीच जुड़ा हुआ है।

// Objects and their basic data

item_id | item
1 | Naginata


// Things that objects can do

trait_id | trait
1 | weapon
2 | holdable

// How those objects do those things, e.g. powerfully, weakly, while on fire

_item_id | _trait_id | item_trait_data
1 | 1 | damage: 5, damage_type: sharp, whatever, etc

मुझे वास्तव में यकीन नहीं है कि अतिरिक्त डेटा को कैसे मॉडल किया जाए (उदाहरण के लिए क्षति जो एक तलवार करेगी, नुकसान_प्रकार, आदि)।

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

क्या इस सामान को रखने का एक बेहतर तरीका है जो मुझे याद आ रहा है?

संपादित करें: मुझे बस ध्यान देना चाहिए कि मुझे साइट पर उपयोग में पहले से ही एक पोस्टग्रेजल डेटाबेस मिला है, यही कारण है कि मैं इसे अपने डेटा भंडारण के लिए उपयोग करना चाहता हूं।

संपादित करें: मैंने कार्यान्वयन के लिए एक उत्तर जोड़ा है जो मैं वर्तमान में देख रहा हूं।

जवाबों:


10

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

पहली बात यह तय करना है कि डेटा किसी वस्तु का कितना विशिष्ट है और किसी दिए गए प्रकार की सभी वस्तुओं द्वारा कितना साझा किया गया है।

यदि सभी डेटा आइटम विशिष्ट हैं तो मैं यहां क्या करूंगा :

// ITEMS table: attributes common to all items
item_id | name        | owner         | location             | sprite_id | ...
1       | Light Saber | 14 (Tchalvek) | 381 (Tchalvek house) | 5663      | ...

// WEAPONS table: attributes for items that are weapons
item_id | damage | damage_type | durability | ...
1       | 5      | sharp       | 13         | ...

// LIGHTING table: attributes for items that serve as lights
item_id | radius   | brightness | duration | ...
1       | 3 meters | 50         | 8 hours  | ...

इस डिज़ाइन में, प्रत्येक आइटम आइटम तालिका में है, विशेषताओं के साथ जो सभी (या अधिकांश) आइटम हैं। प्रत्येक अतिरिक्त भूमिका जो एक आइटम निभा सकता है, एक अलग तालिका है।

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

एक आइटम में कई भूमिकाएँ हो सकती हैं, और एक से अधिक भूमिका-विशिष्ट तालिका (इस उदाहरण में, दोनों हथियार और प्रकाश व्यवस्था) में मौजूद हैं।

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

यदि प्रति डेटा कुछ आइटम अलग-अलग नहीं होंगे, तो अरी की प्रति प्रकार एक अतिरिक्त तालिका होने की सिफारिश भी इस दृष्टिकोण के साथ की जा सकती है। उदाहरण के लिए, यदि हथियार की क्षति प्रति आइटम में भिन्न नहीं होती है, लेकिन भूमिकाएं अभी भी प्रति आइटम में भिन्न होती हैं, तो आप हथियार की विशेषताओं को एक तालिका में साझा कर सकते हैं:

// WEAPONS table: attributes for items that are weapons
item_id | durability | weapon_type
1       | 13         | light_saber

// WEAPONTYPES table: attributes for classes of weapons
weapon_type_id | damage | damage_type
light_saber    | 5      | energy

एक अन्य दृष्टिकोण यह होगा कि आइटम द्वारा निभाई गई भूमिकाएं आइटम द्वारा भिन्न नहीं होती हैं, लेकिन केवल आइटम प्रकार द्वारा। उस स्थिति में आप Item_type को आइटम तालिका में डालेंगे, और "इसे एक हथियार है" और "यह एक धारण योग्य है" जैसे गुणों को संग्रहीत कर सकते हैं और ItemTypes तालिका में "यह एक प्रकाश है"। इस उदाहरण में, मैं आइटम नाम भी प्रति आइटम नहीं बदलता हूं:

// ITEMS table: attributes per item
item_id | item_type    | owner         | location
1       | light_saber  | 14 (Tchalvek) | 381 (Tchalvek house)

// ITEMTYPES table: attributes shared by all items of a type
item_type   | name        | sprite_id | is_holdable | is_weapon | is_light
light_saber | Light Saber | 5663      | true        | true      | true

// WEAPONTYPES table: attributes for item types that are also weapons
item_type   | damage | damage_type
light_saber | 5      | energy

यह संभावना है कि गेम के दौरान आइटमटाइप्स और वेन्टोनिपेस नहीं बदलते हैं, इसलिए आप बस उन तालिकाओं को एक बार मेमोरी में लोड कर सकते हैं, और डेटाबेस में शामिल होने के बजाय हैश तालिका में उन विशेषताओं को देख सकते हैं।


+1। यह एकमात्र उत्तर है जो रिलेशनल डेटाबेस के रूप में रिलेशनल डेटाबेस का उपयोग करता है। इसके अलावा कुछ भी नहीं या नेवरमाइंड के बूँद सुझाव के अन्य चरम और सिर्फ डेटा स्टोर के रूप में डीबी का उपयोग करना, भयानक योजनाएं हैं।

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

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

4

दुर्भाग्य से, इस तरह की स्थितियां ऐसी हैं जहां रिलेशनल डेटाबेस (जैसे एसक्यूएल) कम आते हैं, और गैर-रिलेशनल डेटाबेस (जैसे कि MongoDB ) एक्सेल। कहा जा रहा है, डेटा को रिलेशनल डेटाबेस में मॉडल करना असंभव नहीं है, और चूंकि ऐसा लगता है जैसे आपका कोडबेस पहले से ही एसक्यूएल पर निर्भर है, यहां वह मॉडल है जिसके साथ मैं जाऊंगा:

आइटम बनाने और तालिका का उपयोग करने के बजाय, प्रत्येक आइटम प्रकार के लिए एक तालिका और "[आइटम] _type" संदर्भ तालिका बनाएं।

कुछ उदाहरण निम्नलिखित हैं:

weapon_type_id | weapon_type
1 | sharp

weapon_id | weapon| weapon_type_id | damage
1 | Short Sword | 1 | 5

potion_type_id | potion_type
1 | HP
2 | Mana

potion_id | potion| potion_type_id | modifier
1 | Healing Elixer | 1| 5
2 | Mana Drainer | 2| -5

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

संपादन 1: potion_type_id फ़ील्ड के साथ एक त्रुटि को ठीक किया

संपादित करें 2: अतिरिक्त परिप्रेक्ष्य प्रदान करने के लिए गैर-संबंधपरक बनाम संबंधपरक डेटाबेस पर अधिक विवरण जोड़ा गया


मुझे वास्तव में उस प्रणाली से बहुत अधिक लचीलापन नहीं दिखाई दे रहा है। उदाहरण के लिए, अगर मुझे एक कांच की शीशी चाहिए, जो एक हथियार के रूप में इस्तेमाल की जा सके, और 'तेज' होने के लिए ... ... मैं भाग्य से बाहर हो जाऊंगा। इसके अलावा, हर नए प्रकार के आइटम के लिए, मुझे वास्तव में इसके लिए डेटाबेस संरचना तैयार करनी होगी। भले ही वहाँ केवल एक या दो प्रकार के होने जा रहे थे।
Kzqai

आपके द्वारा लाए जाने वाले बिंदु बहुत ही मान्य हैं, और अतिरिक्त उदाहरण इस बात पर प्रकाश डालते हैं कि रिलेशनल डेटाबेस इस विशिष्ट स्थिति के लिए एक अच्छा फिट क्यों नहीं है। मैंने जो मॉडल प्रस्तुत किया है, वह डेटा को इस तरह से बिछाने का सबसे अच्छा तरीका दिखाता है कि स्मृति संरक्षित है और SQL कार्यक्षमता बरकरार है। उन वस्तुओं को संग्रहीत करने के लिए जो कई प्रकार के होते हैं, इस मॉडल के तहत उस डेटा का प्रतिनिधित्व करने का सबसे अच्छा तरीका उचित पोशन और हथियार गुणों के साथ एक potion_weapon तालिका बनाना होगा। फिर से, यह समाधान आदर्श नहीं है, लेकिन रिलेशनल डेटाबेस का उपयोग करते समय यह सबसे सुरुचिपूर्ण समाधान है।
अरी पैट्रिक

@ श्री: कोई अभद्र इरादा नहीं है, लेकिन उनकी समस्या ठीक है कि संबंधपरक दृष्टिकोण अधिक वैध क्यों है, कम नहीं। यह सर्वविदित है कि NoSQL (या NoRel) डेटाबेस उच्च मात्रा में पढ़े, वितरित / अत्यधिक उपलब्ध डेटा, या खराब-परिभाषित स्कीमा के लिए महान हैं। यह मामला बस एक क्लासिक कई-से-कई संघों का है, और मोंगो जैसे डीबीएस ऐसा नहीं करते हैं और साथ ही आरडीबीएमएस भी। देखें stackoverflow.com/questions/3332093/...
alphadogg

@alphadogg यह कई-कई रिश्ते कैसे हैं? डेटाबेस में, हथियार हथियार प्रकारों के बारे में जानते हैं, लेकिन हथियार प्रकारों को उन हथियारों के बारे में जानने की कोई आवश्यकता नहीं है जिनके साथ वे जुड़े हुए हैं। यदि किसी कारण से आप उन सभी हथियारों को जानना चाहते हैं, जो एक विशिष्ट हथियार प्रकार के हैं, तो आप बस एक प्रश्न लिखेंगे जो हथियार दस्तावेज़ संग्रह पर आधारित है।
अरी पैट्रिक

@ श्री: ओपी के प्रश्न में एक हथियार के कई प्रकार हो सकते हैं, और एक प्रकार को कई हथियारों से जोड़ा जा सकता है। उदाहरण के लिए, एक औषधि और तलवार धारण करने योग्य हैं। एक तलवार धारण करने योग्य और हथियार दोनों है।
अल्फागडग

3

सबसे पहले, ऑब्जेक्ट-ओरिएंटेड इनहेरिटेंस एप्रोच को डंप करें और एक घटक-आधारित सिस्टम के साथ जाएं

एक बार जब आप ऐसा कर लेते हैं, तो SQL लेआउट अचानक बहुत आसान हो जाता है। आपके पास प्रत्येक घटक प्रकार के लिए एक साझा आईडी नंबर के साथ एक तालिका है। यदि आप आइटम # 17 चाहते हैं, तो आप हर तालिका में "आइटम आईडी 17" देखें। कोई भी तालिका जिसमें एक कुंजी होती है, उसके घटक को जोड़ा जाता है।

आपकी आइटम तालिका में सामान्य रूप से आइटमों के लिए सभी आवश्यक डेटा होते हैं (नाम, बिक्री मूल्य, वजन, आकार, कुछ भी जो सभी वस्तुओं के बीच साझा किया जाता है।) आपकी हथियार तालिका में हथियारों के लिए सभी उपयुक्त डेटा होते हैं, आपकी पोशन तालिका में सभी उपयुक्त डेटा होते हैं। औषधि के लिए, आपकी कवच ​​तालिका में कवच के लिए सभी उपयुक्त डेटा होते हैं। ब्रेस्टप्लेट चाहते हैं, वह आइटम में एक प्रविष्टि और कवच में एक प्रविष्टि है। एक ऐसा वर्धमान चाहते हैं, जिसे आप पी सकें, आप बस प्रत्येक टेबल में एक प्रविष्टि रखें, और बैम, आपका काम हो गया।

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


2

SQL का उपयोग करना आपकी गंभीर गलती थी। यह स्थिर गेम-डिज़ाइन डेटा संग्रहीत करने के लिए बिल्कुल अनुकूल नहीं है।

यदि आप एसक्यूएल से दूर नहीं जा सकते हैं, तो मैं इसमें से क्रमबद्ध वस्तुओं को संग्रहीत करने पर विचार करूंगा। अर्थात

item_id (int) | item (BLOB)
1             | <binary data>

बेशक, यह बदसूरत है और खिड़की से बाहर सभी एसक्यूएल "निकेट्स" फेंकता है, लेकिन क्या आपको वास्तव में उनकी आवश्यकता है? शायद, आप अपने सभी आइटम डेटा को खेल में वैसे भी शुरू करते हैं, और इसके अलावा कभी SELECTभी नहीं पढ़ते हैं item_id


3
चूंकि (मेरी समझ से) खेल मल्टीप्लेयर है और PvP का समर्थन करता है, इसलिए संभावना है कि अधिकांश गेमप्ले जानकारी क्लाइंट पर संग्रहीत नहीं है। यदि यह सटीक है, तो हर बार तालिका से डेटा पढ़ा जाता है, इसे दूरस्थ रूप से उपयोगी होने से पहले deserialized करना होगा। नतीजतन, यह प्रारूप उनके गुणों द्वारा वस्तुओं को क्वेरी करना बहुत महंगा है; उदाहरण के लिए: यदि आप "हथियार" प्रकार की सभी वस्तुओं को पुनः प्राप्त करना चाहते हैं, तो आपको प्रत्येक वस्तु को पुनः प्राप्त करना होगा, प्रत्येक को अलग करना होगा, फिर "हथियार" प्रकार के लिए मैन्युअल रूप से फ़िल्टर करना होगा, जैसा कि एक साधारण क्वेरी को चलाने के लिए है। ।
अरी पैट्रिक

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

हम्म, केवल एक चीज यह है कि यह मुझे डेटा को संपादित करने के लिए एक इंटरफ़ेस-साथ छोड़ देता है, जो असुविधाजनक होगा।
Kzqai

2

इस बात पर निर्भर करता है कि आपको कितने लक्षणों की आवश्यकता है, जो अलग-अलग बिट्स के साथ वस्तुओं के लिए एक साधारण बिटकॉम्ब का उपयोग कर सकते हैं।

000001 = holdable
000010 = weapon
000100 = breakable
001000 = throwable
010000 = solids container
100000 = liquids container

फिर आप यह देखने के लिए सरल बिट परीक्षण कर सकते हैं कि क्या किसी वस्तु का उपयोग किसी निश्चित कार्य के लिए किया जा सकता है।

तो "कांच की बोतल" का मूल्य 101111 हो सकता है जिसका अर्थ है कि यह धारण करने योग्य है, एक हथियार के रूप में इस्तेमाल किया जा सकता है, यह आसानी से टूट जाता है, आप इसे फेंक सकते हैं और इसमें तरल पदार्थ हो सकते हैं।

आइटम के लिए आपके द्वारा बनाया गया कोई भी संपादक तब किसी वस्तु पर लक्षणों को सक्षम / अक्षम करने के लिए चेक बॉक्स का एक सरल सेट हो सकता है।


1
मुझे यह विचार पसंद आया, 'क्योंकि यह किसी वस्तु को अपने गुणों को रखने की अनुमति देता है, और मुझे नहीं पता कि मुझे लक्षणों के लिए डेटाबेस की खोज करने की आवश्यकता है, लेकिन मैं वास्तव में यह सुनिश्चित नहीं कर पा रहा हूं कि वह काम कैसे किया जाए एक संबंधपरक संदर्भ में। मुझे लगता है कि प्रत्येक बिट डेटाबेस में लक्षणों की वृद्धिशील आईडी के लिए नक्शा होगा ...
Kzqai

मुझे लगता है कि एक निश्चित संख्या के लक्षणों के लिए बिटमास्किंग अधिक उपयोगी है, हालांकि?
Kzqai

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

1
यदि आप लक्षणों के लिए DB में एक लुकअप तालिका (शायद एक अच्छा विचार है क्योंकि आप उन्हें तब गतिशील रूप से किसी भी संपादक में जोड़ सकते हैं) तो यह सिर्फ इस तरह से कुछ होगा: आईडी, बिटमास्क, विवरण। 1,1, "Holdable"; 2,2, "हथियार"; 3,4, "ब्रेक करने योग्य", आदि निश्चित संख्या के संबंध में, हां यह सच है। लेकिन अगर आप 64 बिट इंट का उपयोग करते हैं तो आपके पास बहुत गुंजाइश होनी चाहिए।
मुत्तले

1

हमारी परियोजना में हमारे पास अलग-अलग "अतिरिक्त डेटा" के लिए आइटम_टैब है जो एक आइटम हो सकता है। यह कुछ इस तरह से रखी गई है:

item_id | attribute_id    | attribute_value | order 
1        25 (attackspeed)       50             3    

फिर हमारे पास एक विशेषता तालिका है जो इस तरह दिखती है:

id |   name       | description
1    attackspeed    AttackSpeed:

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

आपके पास जो दूसरा विकल्प है , वह आइटम टेम्प्लेट बनाने के लिए स्क्रिप्टिंग भाषा का उपयोग कर रहा है, फिर आप उन वस्तुओं को आसानी से पार्स कर सकते हैं और उपयोग कर सकते हैं जो नई आइटम बना सकते हैं। आपको अभी भी डेटाबेस में आइटम डेटा को सहेजना है, लेकिन उस बिंदु पर आपको नए आइटम बनाने की बारीकियों के बारे में चिंता करने की ज़रूरत नहीं है, आप बहुत ही कॉपी और पुरानी स्क्रिप्ट फ़ाइल को कॉपी कर सकते हैं, कुछ जानकारी बदल सकते हैं और आप अच्छे हैं जाना।

ईमानदारी से, यदि हम नए स्टैटिक आइटम बनाते हैं तो हम पुन: करते हैं कि हम स्क्रिप्टिंग आइटम टेम्प्लेट का उपयोग करके बहुत सरल दृष्टिकोण के लिए जाएंगे।


1

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

अपने कोड में एक ORM लेयर करें और आपके पास DB और मिडलवेयर के बीच बहुत कम समस्याएँ होनी चाहिए। कई ओआरएम स्वयं भी कक्षाएं उत्पन्न करने में सक्षम हैं, और इसलिए और भी "अदृश्य" हो जाते हैं।

NoSQL डेटाबेस के रूप में, ऐसा कोई कारण नहीं है कि आप इसे उन लोगों के साथ नहीं कर सकते। वर्तमान में यह ट्रेड रैग्स और ब्लॉग्स में उस तकनीक के लिए चीयरलीड करने के लिए फैशनेबल है, लेकिन वे अपने स्वयं के मुद्दों के साथ आते हैं: अपेक्षाकृत अपरिपक्व प्लेटफॉर्म, साधारण अनिरंतरित-परिवर्तित रीड्स (एक प्रोफ़ाइल में एक-से-कई जुड़वाँ की तरह) के लिए बढ़िया है लेकिन जटिल डायनामिक रीड या अपडेट के लिए खराब, खराब सपोर्टिंग टूलचैन, निरर्थक डेटा और अखंडता मुद्दों के साथ, आदि। हालांकि, वे बेहतर स्केलेबिलिटी की अपील की पेशकश करते हैं क्योंकि वे अलग-अलग डिग्री की ट्रांजेक्शनल क्षमताओं और इसके ऊपरी हिस्से तक पहुंचते हैं, और वितरण / प्रतिकृति के आसान मॉडल। ।

NoSQL डेटाबेस बनाम संबंधपरक डेटाबेस का सामान्य हॉबोब्लिन प्रदर्शन है। विभिन्न RDMBSes में अलग-अलग डिग्री के ओवरहेड शामिल होते हैं जो उन्हें फेसबुक या ट्विटर के स्तरों पर स्केलिंग के लिए कम पसंद करते हैं। हालाँकि, यह बहुत संभावना नहीं है कि आप उन मुद्दों का सामना करेंगे। फिर भी, सरल SSD- आधारित सर्वर सिस्टम प्रदर्शन बहस को बेकार बना सकते हैं।

आइए स्पष्ट हों: अधिकांश NoSQL डेटाबेस को मूल रूप से हैश टेबल वितरित किए जाते हैं, और आपको उसी तरह से अपने कोड में हैश टेबल को सीमित करेगा, अर्थात। सभी डेटा उस मॉडल में अच्छी तरह से फिट नहीं होते हैं। डेटा के बीच मॉडलिंग संबंधों के लिए रिलेशनल मॉडल बहुत अधिक शक्तिशाली है। (भ्रमित करने वाला कारक यह है कि अधिकांश RDBMSes विरासत प्रणाली हैं जो वेब के लोकप्रिय 0.0001% की मांग के लिए खराब ट्यून हैं, अर्थात् फेसबुक एट अल।)


यदि आप उन्हें सामूहिक रूप से संदर्भित करने जा रहे हैं, तो डेटाबेस के बारे में बात करने से भी परेशान न हों। NoSQL एक इकाई नहीं है जिस पर सार्थक चर्चा की जा सकती है, यह एक व्यर्थ जन संदर्भ है जिसका उपयोग SQL fanbois त्रुटिपूर्ण तर्क को लागू करने के लिए करता है कि यदि इस परिभाषित समूह के एक डेटाबेस में एक सुविधा का अभाव है तो उन सभी में उस सुविधा का अभाव है।
आआआआआआ आआआआआ

NoSQL वह शब्द है जिसे NoSQL पुशर्स ने अनुकूलन के लिए चुना था। मुझे पता नहीं क्यों, यह बहुत वर्णनात्मक नहीं है। लेकिन यह किसी प्रकार का सहकर्मी नहीं है। कई लोगों के साथ काम करने के बाद, मुझे लगता है कि उनके बारे में अल्फागॉड का वर्णन उचित है।

हो सकता है कि मेरी टिप्पणी थोड़ी कठोर थी, फिर भी, मैं उस नाम और समूह से नफरत करता हूं, विभिन्न डेटाबेस प्रणालियों के बारीक विवरण के बारे में एक योग्य बहस करना असंभव है जब लोग इस सरलीकृत विश्व दृष्टिकोण को रखते हैं।
aaaaaaaaaaaa

@eBusiness: मुझे आपकी टिप्पणी मनोरंजक लगती है, यह देखते हुए कि यह एंटी-आरडीबीएमएस कैंप है, अगर कोई एक है, तो वह स्वयं अपने प्रौद्योगिकियों के समूह को "नोएसक्यूएल" के रूप में अभिषिक्त करता है। बेशक, उनमें से बहुत से लोग इस नाम को पदावनति में देखना चाहेंगे। विशेष रूप से उनमें से कई अंततः अपने भौतिक कार्यान्वयन पर SQL स्तरित कर रहे हैं। उनके बारे में बात करने के लिए, मैंने आपकी टिप्पणी को कठोर नहीं माना, या मेरी मोटी त्वचा, आपकी पसंद है! :) मेरा मतलब है, एक टी पार्टी के बारे में बात कर सकते हैं, क्यों नहीं डेटाबेस के NoSQL समूह?
अक्षपादयोग

यह उचित है, मैं मानता हूं कि संबंध कई लोगों के लिए पूरी तरह से है। वह चीज जो मुझे वास्तव में सामान्यीकृत शैली में बनाने से रोक रही है, यह सोचा गया है कि "सामान" जो एक आइटम बना देगा, फिर कम से कम दो तालिकाओं में फैल जाएगा। मुझे लगता है कि परमाणु आवेषण बनाने में असमर्थ होने का विचार मुझे पसंद नहीं है।
क्ज़कई

0

यह वह जगह है जहां मुझे वास्तव में उपयोगी होने के लिए अधिक आधुनिक या मैपर्स मिलते हैं, जैसे कि एंटिटी फ्रेमवर्क 4 और इसकी (सीटीपी) कोड-पहली सुविधा । आप सिर्फ नियमित कोड में कक्षाएं और उनके रिलेशनशिप लिखते हैं और यहां तक ​​कि उन्हें सजाने या मैन्युअल रूप से किसी भी उपकरण को चलाने के बिना, ईएफ आपके लिए SQL प्रारूप में बैकिंग स्टोर को आवश्यक लिंक तालिकाओं और सभी के साथ उत्पन्न करेगा ... यह वास्तव में रचनात्मकता को इमोल्ड करता है। ^^


ठीक है, मैं कोड और कक्षाएं बनाऊंगा और वह सब कोड में केवल पहले ... ... इसके बाद मौजूदा डेटाबेस संरचना में अनुवाद करना होगा।
Kzqai

0

यहाँ अब मैं विचार कर रहा हूँ:

चूंकि हर "विशेषता" के लिए अनिवार्य रूप से वैसे भी कोड में बदलाव की आवश्यकता होती है, इसलिए मैंने केवल कोड में लक्षण (और किसी भी डिफ़ॉल्ट डेटा की आवश्यकता है) को कम से कम रखने का फैसला किया है (कम से कम अभी के लिए)।

उदाहरण के लिए $traits = array('holdable'=>1, 'weapon'=>1, 'sword'=>array('min_dam'=>1, 'max_dam'=>500));

तब आइटम को डेटाबेस में "trait_data" फ़ील्ड json_encode()मिलता है जो JSON प्रारूप में संग्रहीत करने के लिए फ़ंक्शन का उपयोग करेगा ।

item_id | item_name | item_identity | traits
1 | Katana | katana | "{"holdable":1,"weapon":1,"sword":{"min_dam":1,"max_dam":1234,"0":{"damage_type":"fire","min_dam":5,"max_dam":50,"type":"thrown","bob":{},"ids":[1,2,3,4,5,6,7]}}}"

योजना यह है कि आइटम अपने माता-पिता के लक्षणों से सभी डिफ़ॉल्ट आँकड़े प्राप्त करेंगे, और केवल ओवर-राइड लक्षण होंगे जो कि उन विशेषताओं से अंतर निर्दिष्ट करते हैं जो लक्षण डिफ़ॉल्ट के रूप में सेट होते हैं।

लक्षण क्षेत्र का नकारात्मक पक्ष यह है कि जब मैं हाथ से जसन भाग को संपादित कर सकता था, ... तो डेटाबेस में डेटा के साथ ऐसा करना वास्तव में आसान या सुरक्षित नहीं होगा।


1
जब आप एक नया लक्षण पेश करते हैं तो क्या होता है? ऐसा कितनी बार हो सकता है? आपके कोड रखरखाव कार्यभार पर बहाव का क्या प्रभाव होगा? उस डेटा को धारण करने के लिए इसे कई-से-कई के रूप में संग्रहीत करें जिससे आपकी ऑब्जेक्ट आवृत्ति गतिशील रूप से निर्मित होती है (ORM की अपनी पसंद के माध्यम से)।
अल्फागदग

धन्यवाद, यह एक अच्छा बिंदु है, नए लक्षण जोड़ना तुच्छ नहीं होने जा रहा है। आपने मेरे विश्लेषण पक्षाघात में जोड़ा है। : पी
क्ज़कई २२'१२ से २२:२०

क्षमा करें, लेकिन यह बहुत महत्वपूर्ण है। आपको बस इसके माध्यम से सोचने की जरूरत है। अपने दिमाग में व्यायाम को मॉडल करें, जब एक नया लक्षण जोड़ने के लिए कुछ हथियारों को अपडेट करने की आवश्यकता होती है, ताकि आपके खेल में वृद्धि हो सके।
१०:२

-1

यह थोड़ा हैकी है, और मैं इसकी कोई गारंटी नहीं देता कि यह अच्छा डीबी डिज़ाइन है; मेरे DB वर्ग कुछ समय पहले थे, और वे जल्दी से मन में नहीं आ रहे थे। लेकिन अगर आइटमों की गारंटी है, तो कहें, 10 से कम आइटम, आप प्रत्येक आइटम को एक विशेषता 1 क्षेत्र, और विशेषता 2 फ़ील्ड दे सकते हैं, और इसी तरह तकसीमा 10। यह विशेषताओं की संख्या को सीमित करने की कीमत पर कई-से-कई आइटम-विशेषता तालिका के लिए आपकी आवश्यकता को समाप्त कर देगा।

उस पर पीछे देखते हुए, मुझे पूरा यकीन है कि यह भयानक डिजाइन है, लेकिन इसका मतलब यह है कि आप एक आरामदायक रिलेशनल डेटाबेस के साथ रह सकते हैं और इसे अनचाहे क्षेत्र में नहीं जाना है। यह तय करना है कि ट्रेड-ऑफ इसके लायक है या नहीं।


यह भयानक डिजाइन है, इसे कभी मत करो। तुम सिर्फ एक डेटाबेस का उपयोग नहीं कर बेहतर होगा।
ZorbaTHut

-1

नेवरमाइंड ने एक अच्छा जवाब दिया, लेकिन मुझे आश्चर्य है कि क्या आपको इसके लिए डेटाबेस की भी आवश्यकता है? सभी डेटा को एक सादे फ़ाइल में संग्रहीत करना और लॉन्च में इसे प्रोग्राम में लोड करना ऐसा करने का सबसे आसान तरीका लगता है।

संपादित करें:
राइट, एक स्टेटलेस अनुरोध संचालित वातावरण में आप बेहतर तरीके से डेटा को डेटाबेस में रखते हैं। अपने डेटा को एक फ़ाइल में लिखें और कोड के एक टुकड़े को लिखें, जिसे नेवरमाइंड द्वारा सुझाए गए प्रकार के डेटाबेस में बदल दिया जाए।

वैकल्पिक रूप से यदि वस्तुओं की संख्या बहुत बड़ी नहीं है, तो कोड फ़ाइल में शाब्दिक रूप से सबसे तेज़ विधि हो सकती है।


Err, मैं पहले ही उपयोग में डेटाबेस प्राप्त कर चुका हूं और बाकी साइट के साथ एकीकृत हूं।
Kzqai
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.