একটি সম্পর্কিত সম্পর্কিত ডাটাবেসের মধ্যে ব্যবহারযোগ্য-ইনভেন্টরি / অবজেক্ট / আইটেমের (যেমন কাতানা) একাধিক "ব্যবহার" (যেমন অস্ত্র) কে কীভাবে মডেল করবেন?


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

আমি কীভাবে অতিরিক্ত ডেটা মডেল করব তা নিশ্চিত নয় (যেমন একটি তরোয়াল যে ক্ষতি করবে, ক্ষতি_প্রকার ইত্যাদি) model

আমি বিশেষত খুশি নই যে কোনও আইটেমের পুরোটি একাধিক জায়গায় সংরক্ষণ করা হবে, যেমন "শর্ট তরোয়াল" এর মতো আলাদা নামের একটি আইটেমের অনুলিপি তৈরি করতে, আমাকে এ থেকে অনুলিপি করতে হবে সদৃশ আইটেমটি তৈরি করতে একাধিক সারণী।

আমি যে জিনিসটি মিস করছি তার বাইরে এই জিনিস দেওয়ার আরও ভাল উপায় কি আছে?

সম্পাদনা: আমার কেবলমাত্র নোট করা উচিত যে আমি ইতিমধ্যে সাইটে একটি পোস্টগ্র্যাসকিএল ডাটাবেস পেয়েছি, যে কারণে আমি এটি আমার ডেটা স্টোরেজের জন্য ব্যবহার করতে চাই।

সম্পাদনা: আমি বর্তমানে বাস্তবায়নের জন্য একটি উত্তর যুক্ত করেছি।

উত্তর:


10

আমি সবার সাথে মৃদুভাবে একমত নই এবং বলতে চাই যে এখানে আপেক্ষিক পদ্ধতিটি যুক্তিযুক্ত। আকর্ষণীয় এখানে আইটেম একাধিক ভূমিকা থাকতে পারে। মূল সমস্যাটি হ'ল এই সম্পর্কের লেআউট এবং কোডের একটি ওও লেআউটের মধ্যে থাকা ম্যাপিংটি "প্রাকৃতিক" বোধ করবে না, তবে আমি মনে করি ডাটাবেসের পক্ষের একাধিক ভূমিকা পরিষ্কারভাবে প্রকাশ করা যেতে পারে (অদ্ভুত এনকোডিংগুলি বা অপ্রয়োজনীয়তা ছাড়াই, কেবল যোগ দেয়) ।

প্রথমে সিদ্ধান্ত নেওয়ার বিষয়টি হ'ল তথ্যটি নির্দিষ্ট পরিমাণে নির্দিষ্ট পরিমাণ এবং প্রদত্ত প্রকারের সমস্ত আইটেম দ্বারা কত ভাগ করে নেওয়া হয়।

সমস্ত ডেটা আইটেম নির্দিষ্ট থাকলে আমি এখানে যা করব :

// 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

আইটেম দ্বারা চালিত ভূমিকা আইটেম অনুসারে পরিবর্তিত হয় না, তবে শুধুমাত্র আইটেম টাইপ দ্বারা অন্য একটি পদ্ধতির হতে হবে। সেক্ষেত্রে আপনি আইটেম_প্রকারটি আইটেম টেবিলের মধ্যে রেখে দিতে পারেন এবং "আইটেম টাইপস টেবিলের" ​​এটি একটি অস্ত্র "এবং" এটি হোল্ডেবল "এবং" এটি কি হালকা "এর মতো বৈশিষ্ট্যগুলি সংরক্ষণ করতে পারেন। এই উদাহরণে আমি আইটেমের নাম আইটেম প্রতি পৃথক নয়:

// 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 তবে এই পদ্ধতিগুলি দারুণ জটিল নয়। আমি যদি অসঙ্গতিপূর্ণ মনে হয় তবে আমি ক্ষমা চাইছি তবে আমি আইটেমগুলির জন্য প্রয়োজনীয়ভাবে একবারে ডাটাবেস স্ট্রাকচার তৈরি করতে সক্ষম হতে চাই ... ... এবং আইটেমগুলির জন্য আরও বৈশিষ্ট্যগুলি কোড করি, আইটেমগুলির জন্য ডাটাবেসে আরও সন্নিবেশ তৈরি করি, তবে পরিবর্তন করতে হবে না ভবিষ্যতে ডাটাবেস আবার (অবশ্যই খুব কম ব্যতিক্রম সহ)।
Kzqai

আপনি যদি ক্ষেত্র সম্পর্কে সম্পর্কিত সম্পর্কিত ডেটাবেস জানতে চান এবং সেগুলির প্রতিনিধিত্ব অনুকূল করতে চান তবে আপনাকে সেগুলি কোথাও যুক্ত করতে হবে। এটি স্থির ধরণের মতো। আপনি যদি চান যে আপনার সংকলকটি আপনার ক্ষেত্রগুলি সম্পর্কে জানতে এবং সেগুলির প্রতিনিধিত্ব অনুকূল করতে চান, আপনাকে প্রকারগুলি ঘোষণা করতে হবে। বিকল্পটি হ'ল ডায়নামিকভাবে টাইপড অ্যাপ্রোচ, যা কিছু ডকুমেন্ট ডাটাবেস দ্বারা ব্যবহৃত হয় বা কোনও উপায়ে সম্পর্কিত ডেটাবেজে আপনার ডেটা এনকোড করে। ডাটাবেসগুলি ক্ষেত্রগুলি কী তা জানবে না বা তাদের সঞ্চয়স্থানটি অনুকূল করতে সক্ষম হবে তবে আপনি কিছুটা নমনীয়তা অর্জন করবেন।
amitp

4

দুর্ভাগ্যক্রমে, এরকম পরিস্থিতি যেখানে রিলেশনাল ডেটাবেসগুলি (যেমন এসকিউএল) সংক্ষিপ্ত হয় এবং অ-সম্পর্কযুক্ত ডাটাবেসগুলি (যেমন মঙ্গোডিবি ) এক্সেল হয়। বলা হচ্ছে, একটি সম্পর্কিত ডেটাবেজে ডেটা মডেল করা অসম্ভব নয় এবং যেহেতু আপনার কোডবেসটি ইতিমধ্যে এসকিউএল এর উপর নির্ভরশীল তাই এখানে আমি যে মডেলটি নিয়ে যাব তা এখানে রয়েছে:

কোনও আইটেম তৈরির পরিবর্তে এবং সারণি ব্যবহারের পরিবর্তে প্রতিটি আইটেমের ধরণের জন্য একটি টেবিল এবং "[আইটেম] _ টাইপ" রেফারেন্স সারণী তৈরি করুন।

এখানে কিছু উদাহরণ আছে:

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

এই সমাধানটি আপনাকে দীর্ঘমেয়াদী নমনীয়তা এবং স্কেলিবিলিটি দেয়, এটি নষ্ট স্থান হ্রাস করে (যদি না বাদ দেয়) এবং স্ব-ডকুমেন্টিং হয় ("আইটেম_স_ডাটা" এর বিপরীতে)। এটি বিকাশকারীর শেষের দিকে আরও কিছুটা সেটআপ জড়িত, তবে আমার মতে এটি এমন পরিস্থিতিতে সর্বাধিক মার্জিত সমাধান যেখানে আপনার ডেটা সংরক্ষণ করার জন্য আপনাকে একটি সম্পর্কিত ডেটাবেস ব্যবহার করতে হবে। সাধারণভাবে বলতে গেলে, গেম উন্নয়নের জন্য অপেক্ষাকৃত ডেটাবেসগুলি অনেক বেশি ভাল, কারণ তারা কীভাবে ডেটা মডেল করে তা আরও নমনীয়, যখন এসকিউএল-ভিত্তিক ডাটাবেসগুলির চেয়ে আরও পারফরম্যান্ট - তাদের একটি "উইন-উইন" পছন্দ করে তোলে।

সম্পাদনা 1: potion_type_id ক্ষেত্রের সাথে একটি ত্রুটি সংশোধন করেছে

সম্পাদনা 2: অতিরিক্ত দৃষ্টিকোণ সরবরাহ করতে অ-সম্পর্কিত সম্পর্কিত বনাম সম্পর্কিত ডেটাবেসগুলিতে আরও বিশদ যুক্ত করা হয়েছে


আমি সত্যিই সেই সিস্টেম থেকে প্রচুর নমনীয়তা দেখতে পাচ্ছি না। উদাহরণস্বরূপ, আমি যদি একটি কাচের শিশি চাইতাম, অস্ত্র হিসাবে ব্যবহার করতে পারি এবং 'তীক্ষ্ণ' হতে পারি ... ... আমি ভাগ্যের বাইরে থাকব। এছাড়াও, প্রতিটি নতুন ধরণের আইটেমের জন্য আমাকে এর জন্য ডাটাবেস কাঠামো তৈরি করতে হবে। এমনকি সেখানে শুধুমাত্র এক বা দুটি ধরণের হতে চলেছে।
Kzqai

আপনি যে পয়েন্টগুলি এনেছেন তা অত্যন্ত বৈধ, এবং কেন এই সম্পর্কযুক্ত ডেটাবেসগুলি এই নির্দিষ্ট পরিস্থিতির জন্য উপযুক্ত নয় additional তার অতিরিক্ত উদাহরণগুলি হাইলাইট করে। আমি যে মডেলটি উপস্থাপন করেছি তা কেবল ডেটা রাখার সর্বোত্তম উপায়টি এমনভাবে দেখায় যাতে মেমরিটি সংরক্ষণ করা হয় এবং এসকিউএল কার্যকারিতা বজায় থাকে। একাধিক প্রকারের আইটেমগুলি সংরক্ষণ করার জন্য, এই মডেলটির অধীনে সেই ডেটা উপস্থাপন করার সর্বোত্তম উপায় হ'ল উপযুক্ত দোশন এবং অস্ত্রের বৈশিষ্ট্য সহ একটি দালান_সাগরণ টেবিল তৈরি করা। আবার, এই সমাধানটি আদর্শ নয়, তবে কোনও রিলেশনাল ডাটাবেস ব্যবহার করার সময় এটি সর্বাধিক মার্জিত সমাধান।
এরি প্যাট্রিক

@ আরি: কোনও অনাদরের উদ্দেশ্যে নয়, তবে তাঁর সমস্যাটিই স্পষ্টতই কেন এই সম্পর্কের বিষয়টি আরও বৈধ, কম নয়। এটি সুপরিচিত যে NoSQL (বা NoRel) ডাটাবেসগুলি উচ্চ-ভলিউম পাঠ, বিতরণ / উচ্চ-উপলভ্য ডেটা বা দুর্বল-সংজ্ঞায়িত স্কিমার জন্য দুর্দান্ত। এই কেসটি কেবল একটি ক্লাসিক অনেকগুলি থেকে বহু সংঘবদ্ধতা, এবং মঙ্গোর মতো ডিবিএস আরডিবিএমএস হিসাবে এটি করে না। দেখুন stackoverflow.com/questions/3332093/...
alphadogg

@ পালাডোগগ এটি কীভাবে বহু-বহু সম্পর্ক? ডাটাবেসে, অস্ত্রগুলি অস্ত্রের প্রকারগুলি সম্পর্কে জানে, তবে অস্ত্রের ধরণগুলির সাথে তারা যে অস্ত্রগুলি যুক্ত সেগুলি সম্পর্কে জানার দরকার নেই। যদি কোনও কারণে আপনি নির্দিষ্ট অস্ত্র ধরণের সমস্ত অস্ত্র জানতে চান তবে আপনি কেবল একটি কোয়েরি লিখবেন যা অস্ত্র নথি সংগ্রহের মাধ্যমে পুনরাবৃত্তি করে।
এরি প্যাট্রিক

@ অরি: ওপির প্রশ্নে একটি অস্ত্রের অনেক ধরণের থাকতে পারে এবং এক ধরণের অনেকগুলি অস্ত্রের সাথে সংযুক্ত থাকতে পারে। উদাহরণস্বরূপ, একটি দমন এবং একটি তরোয়াল ধারণযোগ্য। একটি তরোয়াল হোল্ডযোগ্য এবং অস্ত্র উভয়ই।
আলফাডোগ

3

প্রথমে, অবজেক্ট-ভিত্তিক উত্তরাধিকারের পদ্ধতির ডাম্প করুন এবং একটি উপাদান-ভিত্তিক সিস্টেমের সাথে যান ।

এটি করা হয়ে গেলে, এসকিউএল লেআউট হঠাৎ করে আরও সহজ হয়ে যায়। আপনার ভাগ করা আইডি নম্বর সহ প্রতিটি উপাদান টাইপের জন্য একটি টেবিল রয়েছে। আপনি যদি আইটেম # 17 চান তবে প্রতিটি সারণীতে আপনি "আইটেম আইডি 17" সন্ধান করতে পারেন। কী রয়েছে এমন যে কোনও সারণীতে এর উপাদান যুক্ত হয়ে যায়।

আপনার আইটেমের টেবিলটিতে সাধারণভাবে আইটেমগুলির জন্য প্রয়োজনীয় সমস্ত ডেটা রয়েছে (নাম, বিক্রয় মূল্য, ওজন, আকার, সমস্ত আইটেমের মধ্যে ভাগ করে নেওয়া অন্য কিছু)) আপনার অস্ত্র টেবিলটিতে অস্ত্রগুলির জন্য সমস্ত উপযুক্ত ডেটা রয়েছে, আপনার পোশন সারণিতে সমস্ত উপযুক্ত ডেটা রয়েছে রক্তের জন্য, আপনার আর্মার টেবিলটিতে বর্মের জন্য সমস্ত উপযুক্ত ডেটা রয়েছে। ব্রেস্টলেট চাই, এটি আইটেমের একটি এন্ট্রি এবং আর্মারে একটি এন্ট্রি আপনি পান করতে পারেন এমন একটি তরোয়ালহেল চান, আপনি প্রতিটি টেবিলের মধ্যে কেবল একটি এন্ট্রি রেখেছিলেন এবং বাম, আপনি শেষ করেছেন।

মনে রাখবেন যে এই একই প্যাটার্নটি বিশেষভাবে আইটেম-নির্দিষ্ট নয় - আপনি এটি প্রাণী, অঞ্চল, আপনার পছন্দসই যে কোনও কিছুর জন্য ব্যবহার করতে পারেন। এটি আশ্চর্যজনকভাবে বহুমুখী।


2

এসকিউএল ব্যবহার করা আপনার গুরুতর ভুল ছিল। স্থির গেম-ডিজাইন ডেটা সংরক্ষণ করার জন্য এটি একেবারেই উপযুক্ত নয়।

আপনি যদি এসকিউএল থেকে সরে যেতে না পারেন তবে আমি এখান থেকে সিরিয়ালযুক্ত আইটেমগুলি সংরক্ষণ করার বিষয়টি বিবেচনা করব। অর্থাত

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

অবশ্যই, এটি কুৎসিত এবং সমস্ত এসকিউএল "চমত্কার" উইন্ডো থেকে ছুঁড়ে ফেলেছে, তবে আসলে আপনার এগুলি দরকার ? আপনারা নিশ্চয় আপনার আইটেমটি সমস্ত ডেটা পড়তে খেলা কখনোই যাহাই হউক না কেন শুরু, এবং SELECTছাড়া অন্য যেকোনো উপায়ে item_id


3
যেহেতু (আমার বোঝার দিক থেকে) গেমটি মাল্টিপ্লেয়ার এবং পিভিপি সমর্থন করে, তাই সম্ভবত বেশিরভাগ গেমপ্লে তথ্য ক্লায়েন্টে সংরক্ষণ করা হয় না। যদি এটি সঠিক হয়, তবে প্রতিবারের টেবিল থেকে ডেটা পড়লে, দূরবর্তীভাবে কার্যকর হওয়ার আগে এটি ডিসরিয়ালাইজ করতে হবে। ফলস্বরূপ, এই ফর্ম্যাটটি তাদের সম্পত্তিগুলির দ্বারা আইটেমগুলি অনুসন্ধান করা খুব ব্যয়বহুল করে তোলে; উদাহরণস্বরূপ: আপনি যদি "অস্ত্র" টাইপের সমস্ত আইটেম পুনরুদ্ধার করতে চান তবে আপনাকে প্রতিটি আইটেমটি পুনরুদ্ধার করতে হবে, প্রত্যেককেই ডিজিটালাইজ করতে হবে, তারপরে "অস্ত্র" টাইপের জন্য ম্যানুয়ালি ফিল্টার করতে হবে, সাধারণ জিজ্ঞাসা চালানোর বিপরীতে ।
এরি প্যাট্রিক

1
আমার অভিজ্ঞতা থেকে, সমস্ত আইটেম যেভাবেই হোক না কেন খেলার শুরুতে মেমরি ক্যাশে পড়ে read সুতরাং আপনি কেবল একবার প্রারম্ভের সময় এগুলি deserialize, এবং পরে ডেটাবেস ব্যবহার করবেন না। যদি এই ক্ষেত্রে এটি না হয়, তবে আমি সম্মত হই, সিরিয়ালযুক্ত জিনিসগুলি সংরক্ষণ করা একটি খারাপ ধারণা।
কিছু মনে করবেন না

হুঁ, কেবলমাত্র এটি হ'ল এটি আমাকে একটি ইন্টারফেসের সাথে ফেলে রেখেছিল - প্রয়োজনীয় ডেটা সম্পাদনা করার জন্য, যা অসুবিধে হবে।
Kzqai

2

আপনার যে কয়টি বৈশিষ্ট্যের প্রয়োজন হতে পারে তার উপর নির্ভর করে আপনি বিভিন্ন বিটগুলির সাথে বিভিন্ন বিটগুলি সহ অবজেক্টগুলির জন্য একটি সাধারণ বিটমাস্ক ব্যবহার করতে পারেন:

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

তারপরে আপনি কোনও নির্দিষ্ট ফাংশনের জন্য কোনও অবজেক্ট ব্যবহার করা যায় কিনা তা দেখতে আপনি সাধারণ বিট পরীক্ষা করতে পারেন।

সুতরাং "কাচের বোতল" এর 101011 এর মান থাকতে পারে যার অর্থ এটি ধরে রাখা যায়, এটি একটি অস্ত্র হিসাবে ব্যবহার করা যেতে পারে, এটি সহজেই ভেঙে যায়, আপনি এটি নিক্ষেপ করতে পারেন এবং এতে তরল থাকতে পারে।

আইটেমগুলির জন্য আপনি যে কোনও সম্পাদক তৈরি করেন তার পরে কোনও বস্তুর বৈশিষ্ট্যগুলি সক্ষম / অক্ষম করার জন্য চেক বাক্সগুলির একটি সহজ সেট থাকতে পারে।


1
আমি ধারণাটি পছন্দ করি, 'কারণ এটি কোনও আইটেমকে তার নিজস্ব বৈশিষ্ট্য ধারণ করার অনুমতি দেয় এবং আমি জানি না যে আমাকে বৈশিষ্ট্যের জন্য ডেটাবেস সন্ধান করতে হবে, তবে কীভাবে কীভাবে এটি তৈরি করা যায় তা আমি নিশ্চিতভাবে জানি না একটি সম্পর্কযুক্ত প্রসঙ্গে। আমি অনুমান করি যে প্রতিটি বিট ডাটাবেসে বৈশিষ্ট্যের বর্ধিত
আইডিতে

আমার ধারণা বিটমাস্কিং একটি নির্দিষ্ট সংখ্যক বৈশিষ্ট্যের জন্য আরও কার্যকর, যদিও?
Kzqai

খুব বেশী তাই. আপনি যদি আপনার শেষ "বিট" ব্যবহার করেন তবে কী হবে? আপনার অ্যাপ্লিকেশন স্তরের মাধ্যমে কিছুটা বাড়ানোর জন্য এবং এটির জন্য একটি কলাম যুক্ত করতে এবং এটি করার জন্য ডেটা ধরণের বাড়ানো কত সহজ? এছাড়াও, আপনার নির্দিষ্ট ডাটাবেস ইঞ্জিনটি কি বিট ক্রিয়াকলাপের জন্য সূচীকরণের জন্য সুরক্ষিত? ডেটা কলামের সাথে পারমাণবিক থাকার জন্য এটি একটি সম্পর্কিত ডেটাবেজে সেরা। এক কলামে একাধিক ডোমেন একসাথে করবেন না। আপনি প্ল্যাটফর্মের সুবিধাগুলিতে আলতো চাপতে পারবেন না।
আলফাডোগ

1
আপনি যদি বৈশিষ্ট্যের জন্য ডিবিতে একটি সারণী চেয়েছিলেন (সম্ভবত একটি ভাল ধারণা হিসাবে আপনি এগুলি তখন কোনও সম্পাদকের সাথে ডায়নামিকভাবে যুক্ত করতে পারেন) তবে এর ঠিক এই জাতীয় কিছু থাকবে: আইডি, বিটমাস্ক, বিবরণ। 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

এটি আপনার সাধারণ অনেকগুলি থেকে বেশি সম্পর্ক, কোনও সক্ষম রিলেশনাল ডাটাবেসের জন্য খুব বেশি গুরূত্বপূর্ণ কিছুই নয়। আপনার যে কোনও একটি অবজেক্টের জন্য অনেকগুলি বৈশিষ্ট্য রয়েছে এবং যে কোনও একটি বৈশিষ্ট্য এক বা একাধিক পৃথক অবজেক্টের ধরণের দ্বারা ব্যবহৃত হতে পারে। মডেল তিনটি সম্পর্ক (সারণী), যার একটি হ'ল একটি সম্পর্ক being যথাযথ সূচকগুলি আপনাকে দ্রুত ডেটা পড়ার আশ্বাস দেয়।

আপনার কোডটিতে একটি ওআরএম স্তর রাখুন এবং আপনার ডিবি এবং মিডলওয়্যারের মধ্যে খুব কম সমস্যা হবে। অনেকগুলি ওআরএম নিজেরাই ক্লাসগুলি স্বয়ংক্রিয়ভাবে তৈরি করতে সক্ষম হয় এবং তাই আরও "অদৃশ্য" হয়ে যায়।

নোএসকিউএল ডাটাবেস হিসাবে, কোনও কারণ নেই যে আপনি সেগুলি দিয়ে এটি করতে পারবেন না। ট্রেড র‌্যাগ এবং ব্লগগুলিতে সেই প্রযুক্তির জন্য চিয়ারলিড করার জন্য বর্তমানে এটি ফ্যাশনেবল, তবে এগুলি তার নিজস্ব কয়েকটি ইস্যু নিয়ে আসে: তুলনামূলকভাবে অপরিণত প্ল্যাটফর্ম, সহজ-সরল-পরিবর্তিত পড়ার জন্য দুর্দান্ত (কোনও প্রোফাইলে এক থেকে একাধিক বারের মত) তবে জটিল গতিশীল পাঠ বা আপডেটের জন্য দুর্বল, দুর্বল সমর্থনকারী সরঞ্জামচেন, রিডানড্যান্ট ডেটা এবং তার সাথে সংযুক্তি সম্পর্কিত সমস্যা ইত্যাদি etc. তবে তারা আরও ভাল স্কেল্যাবিলিটির আবেদন দেয় কারণ তারা বিভিন্ন ডিগ্রি লেনদেনের ক্ষমতা এবং এর ওভারহেড, এবং বিতরণ / প্রতিলিখনের সহজ মডেলগুলির উপর নির্ভরশীল ।

NoSQL ডাটাবেস বনাম রিলেশনাল ডাটাবেসের সাধারণ হবগোব্লিন হল পারফরম্যান্স। বিভিন্ন আরডিএমবিএসের ওভারহেডের বিভিন্ন ডিগ্রি জড়িত থাকে যা তাদের ফেসবুক বা টুইটারের স্তরে স্কেলিংয়ের জন্য কম পছন্দ করে তোলে। তবে, আপনি এই সমস্যাগুলির মুখোমুখি হবেন এটা খুব সম্ভব নয়। তারপরেও, সাধারণ এসএসডি-ভিত্তিক সার্ভার সিস্টেমগুলি পারফরম্যান্স বিতর্ককে অকেজো করতে পারে।

আসুন পরিষ্কার হয়ে উঠুন: বেশিরভাগ নুএসকিউএল ডাটাবেসগুলি হ্যাশ টেবিলগুলি মৌলিকভাবে বিতরণ করা হয় এবং আপনাকে আপনার কোডে যেমন একটি হ্যাশ টেবিল দেয় তেমনভাবে সীমাবদ্ধ রাখে ie সমস্ত তথ্য যে মডেল ভাল ফিট করে না। রিলেশনাল মডেল ডেটার মধ্যে সম্পর্কের মডেলিংয়ের জন্য অনেক বেশি শক্তিশালী। (বিভ্রান্তিকর কারণটি হ'ল বেশিরভাগ আরডিবিএমএস হ'ল লিগ্যাসি সিস্টেম যা জনপ্রিয় 0.0001% ওয়েবের চাহিদা, যেমন ফেসবুক এট এর জন্য খুব খারাপভাবে সুর করা হয়))


আপনি যদি তাদের সম্মিলিতভাবে উল্লেখ করতে চলেছেন, এমনকি ডাটাবেস সম্পর্কে কথা বলতে বিরক্ত করবেন না। নোএসকিউএল কোনও সত্তা নয় যা অর্থপূর্ণভাবে আলোচনা করা যেতে পারে, এটি এসকিউএল ফ্যানবোইস ত্রুটিযুক্ত যুক্তি প্রয়োগ করতে ব্যবহার করে যে এই সংজ্ঞায়িত গোষ্ঠীর একটি ডাটাবেসের যদি কোনও বৈশিষ্ট্যের অভাব থাকে তবে তাদের সকলেরই সেই বৈশিষ্ট্যের অভাব রয়েছে।
আআআআআআআআআআআআআআআআআ

নোএসকিউএল হ'ল নোএসকিউএল পুশাররা অভিযোজন করতে বেছে নিয়েছে। আমি জানি না কেন, এটি খুব বর্ণনামূলক নয়। তবে এটি কোনও ধরণের অবয়ব নয়। বেশ কয়েকজনের সাথে কাজ করার পরে, আমি মনে করি যে তাদের সম্পর্কে বর্ণমালার বর্ণনটি ন্যায্য।

সম্ভবত আমার মন্তব্যটি কিছুটা কঠোর ছিল, তবুও, আমি সেই নামটি এবং গোষ্ঠীকরণকে ঘৃণা করি, লোকেরা যখন এই সরলীকৃত বিশ্ব দৃষ্টিভঙ্গি রাখে তখন বিভিন্ন ডাটাবেস সিস্টেমের সূক্ষ্ম বিবরণ সম্পর্কে যোগ্য বিতর্ক করা অসম্ভব।
আআআআআআআআআআআআআআআআআআআচ

@ ই বিজনেস: আমি আপনার মন্তব্যকে মজাদার মনে করি, এটি দেওয়া হয়েছে যে এটি আরডিবিএমএস বিরোধী শিবির, যদি সেখানে একটি থাকে, যে তাদের প্রযুক্তিগুলির "নোএসকিউএল" হিসাবে আত্ম-অভিষিক্ত করে। স্বীকারোক্তিজনকভাবে, তাদের মধ্যে অনেকেই এই নামটিকে অন্ধকারে অবহেলিত দেখতে চান। বিশেষত তাদের অনেকেই শেষ পর্যন্ত তাদের শারীরিক বাস্তবায়নের উপর এসকিউএল রাখছেন। তাদের সম্পর্কে কথা বলার জন্য, আমি আপনার মন্তব্যটি কঠোর হিসাবে গ্রহণ করি নি, বা আমার ত্বক পুরু আছে, আপনার পছন্দ! :) আমি বলতে চাইছি, কেউ চা পার্টি সম্পর্কে কথা বলতে পারেন, নোএসকিউএল গ্রুপ ডাটাবেস কেন নয়?
আলফাডোগ

এটি ন্যায্য, আমি বুঝতে পারি যে সম্পর্কটি অনেকের কাছে একেবারে সম্পূর্ণ। যে জিনিসটি আমাকে সত্যিকারের স্বাভাবিক স্টাইলে তৈরি করতে বাধা দিচ্ছে তা হ'ল ভাবনাটি যে "স্টাফ" যা কোনও আইটেম তৈরি করবে তা কমপক্ষে দুটি টেবিল জুড়ে ছড়িয়ে দেওয়া হবে। আমি মনে করি পরমাণু সন্নিবেশ তৈরি করতে অক্ষম হওয়ার ধারণাটি আমি পছন্দ করি না।
Kzqai

0

এখান থেকে আমি আরও আধুনিক বা ম্যাপারকে সত্যিকারের উপযোগী হিসাবে দেখতে পাই, যেমন সত্তা ফ্রেমওয়ার্ক 4 এবং এর (সিটিপি) কোড-প্রথম বৈশিষ্ট্য । আপনি কেবল নিয়মিত কোডে ক্লাস এবং তাদের সম্পর্কিত সম্পর্ক লিখুন এবং সেগুলি সাজাতে বা ম্যানুয়ালি কোনও সরঞ্জাম পরিচালনা না করেই, EF আপনার জন্য এসকিউএল ফর্ম্যাটে প্রয়োজনীয় লিঙ্ক টেবিল এবং সমস্ত সহ ব্যাকিং স্টোর তৈরি করবে ... এটি সত্যই সৃজনশীলতার ইমো প্রকাশ করে ^^


ঠিক আছে, আমি কোড এবং ক্লাসগুলি এবং কোডগুলিতে কেবল প্রথম তৈরি করব ... ... কেবলমাত্র এটি বিদ্যমান ডাটাবেস কাঠামোর পরে অনুবাদ করতে হবে।
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
আপনি যখন একটি নতুন বৈশিষ্ট্য প্রবর্তন করেন তখন কী ঘটে? কত ঘন ঘন এমন হতে পারে? আপনার কোড রক্ষণাবেক্ষণ কাজের চাপের উপরের প্রবাহের প্রভাবগুলি কী হবে? এটি একটি বহু-বহু-হিসাবে সংরক্ষণের সাথে বৈপরীত্য করুন যার মাধ্যমে আপনার ডেটা ধরে রাখার জন্য আপনার অবজেক্টের দৃষ্টান্তগুলি গতিশীলভাবে তৈরি করা হয়েছে (আপনার ওআরএম পছন্দ হিসাবে) hold
আলফাডোগ

ধন্যবাদ, এটি একটি ভাল বিষয়, নতুন বৈশিষ্ট্য যুক্ত করা তুচ্ছ হবে না। আপনি আমার বিশ্লেষণ পক্ষাঘাতে যুক্ত করেছেন। : পি
Kzqai

দুঃখিত, তবে এটি বেশ সমালোচনামূলক। আপনার কেবল এটির মাধ্যমে চিন্তা করা দরকার। আপনার গেম বর্ধন কাজ করতে পারে যাতে একটি নতুন বৈশিষ্ট্য যুক্ত করার জন্য যখন কিছু অস্ত্র আপডেট করা দরকার তখন আপনি কী করতে হবে তা সম্পর্কে আপনার মনের অনুশীলনের মডেল করুন।
alphadogg

-1

এটি কিছুটা হ্যাকি, এবং আমি এটির ভাল ডিবি ডিজাইনের কোনও গ্যারান্টি দিচ্ছি না; আমার ডিবি ক্লাসগুলি কিছুক্ষণ আগে ছিল এবং সেগুলি খুব দ্রুত মনে আসবে না। তবে যদি আইটেমগুলি 10 টিরও কম আইটেমের গ্যারান্টিযুক্ত থাকে তবে আপনি প্রতিটি আইটেমকে একটি বৈশিষ্ট্য 1 ক্ষেত্র এবং বৈশিষ্ট্য 2 ক্ষেত্র দিতে পারেন এবং তাই 10 পর্যন্ত বৈশিষ্ট্য পর্যন্ত। এটি গুণাবলীর সংখ্যা সীমাবদ্ধ করে ব্যয় করে বহু থেকে বহু আইটেম-বৈশিষ্ট্য টেবিলের জন্য আপনার প্রয়োজনীয়তা দূর করবে।

এটি ফিরে তাকানো, আমি এটি নিশ্চিত যে এটি ভয়ানক নকশা, তবে এর অর্থ আপনি একটি আরামদায়ক রিলেশনাল ডাটাবেসটি আটকে রাখতে পারেন এবং অরক্ষিত অঞ্চলে যেতে হবে না। ট্রেড-অফের পক্ষে এটি উপযুক্ত কিনা তা সিদ্ধান্ত নেওয়া আপনার পক্ষে।


এটি ভয়ানক ডিজাইন, এটি কখনই করবেন না। আপনি কেবলমাত্র একটি ডাটাবেস ব্যবহার না করাই ভাল।
জোর্বাথুত

-1

মাইন্ডমাইন্ড একটি ভাল উত্তর দিয়েছে, তবে আমি অবাক হয়েছি, এর জন্য আপনার কি কোনও ডাটাবেস দরকার? একটি প্লেন ফাইলে সমস্ত ডেটা সংরক্ষণ করা এবং প্রবর্তনকালে এটিকে প্রোগ্রামের মধ্যে লোড করা এটিকে করার মতো স্মার্ট উপায় বলে মনে হয়।

সম্পাদনা:
ঠিক আছে, একটি রাজ্যহীন অনুরোধ চালিত পরিবেশে আপনি ডেটাবেসে ডেটাটি আরও ভাল রাখবেন। কোনও ফাইলের মধ্যে আপনার ডেটা লিখুন এবং কোনও ধরণের কোড লিখুন যাতে এটিকে নেভারমাইন্ড টাইপের প্রস্তাবিত ডেটাবেজে পরিণত করা যায়।

পর্যায়ক্রমে যদি কোনও কোড ফাইলে আক্ষরিক অর্থে বস্তুর সংখ্যা অনেক বড় না হয় তা দ্রুততম পদ্ধতি হতে পারে।


এর, আমি ইতিমধ্যে ব্যবহারের জন্য একটি ডেটাবেস পেয়েছি এবং বাকী সাইটের সাথে সংহত করেছি।
Kzqai
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.