এটি কি আমাদের এমএমওআরপিজি মোবাইল গেমের জন্য সঠিক স্থাপত্য?


14

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

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

উচ্চ-স্তরের প্রবাহ ডায়াগ্রাম

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

এই মডেলটি স্থানে রেখে, আমি নিম্নলিখিত বিষয়গুলি কীভাবে মোকাবেলা করব তা নিশ্চিত নই:

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

আমি নিশ্চিত নই যে এটি একটি কার্যকর সমাধান এবং এটি কীভাবে মাপবে। আমি ইতিমধ্যে প্রশংসা করব যদি এই জাতীয় অ্যাপগুলিতে ইতিমধ্যে কাজ করা লোকেরা তাদের অভিজ্ঞতাগুলি ভাগ করতে পারে যা আমাকে আরও ভাল কিছু নিয়ে আসতে সহায়তা করতে পারে help আগাম ধন্যবাদ.

অতিরিক্ত তথ্য:

ক্লায়েন্ট-সাইডটি সি ++ গেম ইঞ্জিনে প্রয়োগ করা হয় যা মার্বেল বলে। এটি একটি ক্রস প্ল্যাটফর্ম গেম ইঞ্জিন যার অর্থ আপনি সমস্ত বড় মোবাইল ওএসে আপনার অ্যাপটি চালাতে পারেন। আমরা অবশ্যই থ্রেডিং অর্জন করতে পারি এবং এটি আমার ফ্লো ডায়াগ্রামেও চিত্রিত হয়। আমি সার্ভারের জন্য মাইএসকিউএল এবং ক্লায়েন্টের জন্য এসকিউএলাইট ব্যবহার করার পরিকল্পনা করছি।

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

ডাটাবেস সিঙ্ক্রোনাইজের জন্য আমার মনে দুটি সমাধান রয়েছে:

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

2
আমি এমএসএসকিউএল এবং এর সাথে ফিডলের মূল্যায়ন ধরব - আমি নিশ্চিত নই যে মাইএসকিউএল প্রতিলিপির ক্ষেত্রে কী সরবরাহ করে তবে এমএসএসকিউএল ২০০৮ আর 2 আপনাকে একটি লুপ রেপ্লিকেশন (5-6) কৌশল বেছে নিতে দেয়। মাইএসকিউএল বা অন্য কিছুকে ঘৃণা না করে কেবল একটি চিন্তাভাবনা, তবে মাইক্রোসফ্ট ক্লাস্টারিংয়ে সত্যই ভাল।
জোনাথন ডিকিনসন

1
@ জোনাথন ডিকিনসন: মাইএসকিউএল ক্লাস্টার রয়েছে: পি
কোয়েট

1
পোস্টগ্র্রেএসকিউএল দেখুন - সংস্করণ 9 এর প্রতিরূপ প্রযুক্তি রয়েছে, পোস্টগ্রিএসকিউএলকে ভারী বোঝা সত্যিই পরিচালনা করার জন্য একটি দীর্ঘ দীর্ঘস্থায়ী খ্যাতি রয়েছে, বিকাশকারীদের মধ্যে অনেকগুলি অপ্টিমাইজেশন বাদাম বলে মনে হয় এবং সর্বোপরি এর উন্মুক্ত উত্স এবং সমস্ত ব্যবহারের জন্য সম্পূর্ণ বিনামূল্যে (বাণিজ্যিক সহ)
র্যান্ডল্ফ রিচার্ডসন

জিনিসটি হ'ল আমরা ক্লায়েন্ট এবং সার্ভারে একই ডাটাবেস ব্যবহার করতে পারি না। আমি মনে করি ক্লায়েন্টের জন্য সর্বাধিক উপযুক্ত ডিবি এসকিউএলাইট হবে যাতে এটি প্রচুর সংস্থান গ্রহণ না করে কারণ অ্যাপ্লিকেশনটি মোবাইল ডিভাইসে চলমান। সার্ভার অংশে কাজ করা ব্যক্তিটি কেবল মাইএসকিউএলকে জানেন তাই আমরা এটির জন্য নির্বাচন করেছি। এছাড়াও আমি শুনেছি বেশিরভাগ এমএমও গেমস মাইএসকিউএল ডাটাবেস ব্যবহার করে।
umair

1
@ ওমাইয়ার: ক্লায়েন্টের পক্ষ এসকিউএলাইট হতে পারে (আইফোনে এটি ইতিমধ্যে উপলব্ধ)। তবে আপনি কেবল কোনও ফাইলে আপনার প্রয়োজনীয় প্রাসঙ্গিক ডেটা সংরক্ষণ করতে পারবেন (এসকিউএলাইট যাইহোক কী করে) এবং জাভাস্ক্রিপ্ট অ্যাপ্লিকেশনটির সাথে ক্লায়েন্ট সাইড ডিবি-এর মতো সমস্ত ধরণের বিরক্ত না করা like
কোয়েট

উত্তর:


15

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

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

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

কিছু গেম এমনকি একটি স্থানীয় ডিবি ব্যবহার করে না, তারা যখন প্রয়োজন তখন সার্ভার থেকে প্রাসঙ্গিক তথ্য পুল করে স্ট্যাটাসের উপর নজর রাখে।

যদি স্থানীয় ইভেন্টগুলি হারানো গ্রহণযোগ্য না হয় তবে হ্যাঁ, আপনার স্থানীয় সঞ্চয়স্থান থাকা উচিত এবং যতক্ষণ সম্ভব এই স্টোরেজে সংরক্ষণ করা উচিত। প্রতিটি নেটওয়ার্ক প্রেরণের আগে আপনি এটি করার চেষ্টা করতে পারেন।

সক্রিয় ব্যবহারকারীদের অনুসন্ধানের জন্য আমরা প্রতি 20 সেকেন্ডে একটি সফল গেমটিতে এইচটিটিপি দিয়ে পিং করতাম ... সার্ভারগুলি ওভারলোড হয়ে যাওয়ায় এই মানটি তত্ক্ষণাত্ বেড়ে গেছে :( সার্ভার দলটি সাফল্যের কথা ভাবেনি So তাই আমি আপনাকে যুক্ত করতে বলব আপনার যোগাযোগ প্রোটোকলটিতে একটি বার্তা বা কোনও বিশেষ শিরোনাম যা আপনাকে আপনার ক্লায়েন্টদের পুনরায় কনফিগার করতে দেয় (পিং ফ্রিকোয়েন্সি লোড ব্যালেন্সিং এবং অন্যান্য যোগাযোগ সম্পর্কিত মানগুলির জন্য)।

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

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

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

আপনার অনেক কিছু করার আছে তবে এটি একটি মজাদার কাজ ... তাই উপভোগ করুন!


3
'HTML সম্ভবত যথেষ্ট ভাল হচ্ছে' এর জন্য +1 কারণ এটি সম্ভবত :)।
জোনাথন ডিকিনসন

1
@ কোয়েট: সময় ব্যয় করার জন্য এবং এ জাতীয় বিস্তারিত উত্তর দেওয়ার জন্য ধন্যবাদ। অন্যান্য ক্লায়েন্টদের সহায়তা সরবরাহ করার জন্য সত্যই আপনার এইচটিটিপি আইডিয়াটি পছন্দ করুন।
umair

1
বাহিনীটি আপনার সাথে থাকুক :)
কোয়েট

5

সার্ভার এবং ক্লায়েন্ট ডাটাবেস সিঙ্ক্রোনাইজ করার সর্বোত্তম উপায় কী হবে?

সবচেয়ে সহজ উপায় হ'ল আপনি স্থানান্তর করতে পারেন এমন একক ফাইল হিসাবে ডাটাবেস বাস্তবায়ন করা। আপনি যদি ডাটাবেসের মধ্যে পার্থক্য তুলনা করার চেষ্টা করে যান তবে তা ব্যথার জগত এবং আমি অভিজ্ঞতা থেকে বলি।

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

কোনও ইভেন্টটি সার্ভারে আপডেট করার আগে স্থানীয় ডিবিতে সংরক্ষণ করা উচিত?

না, যদি সার্ভার সিদ্ধান্ত নেয় যে ঘটনাটি কখনই ঘটেছিল না? ক্লায়েন্টকে যাইহোক ইভেন্টগুলি সম্পর্কে সিদ্ধান্ত নেওয়া উচিত নয়, কারণ ক্লায়েন্টকে বিশ্বাস করা যায় না।

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

সাধারণ এইচটিটিপি অনুরোধগুলি কী সিঙ্ক্রোনাইজেশনের উদ্দেশ্যে কাজ করবে?

হ্যাঁ, তারা সরবরাহ করা মোটামুটি কম বা খুব কম। এইচটিটিপি ব্যান্ডউইথ-দক্ষ নয় তাই মনে রাখবেন।

কোন ব্যবহারকারী বর্তমানে লগ ইন করেছেন তা কীভাবে জানবেন? (একটি উপায় হ'ল ক্লায়েন্টটি প্রতি x মিনিটের পরে সার্ভারে একটি অনুরোধ প্রেরণ করে এটি সক্রিয় কিনা তা জানাতে পারেন Otherwise অন্যথায় কোনও ক্লায়েন্টকে নিষ্ক্রিয় মনে করুন)।

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

ক্লায়েন্ট পক্ষের বৈধতা কি যথেষ্ট? যদি তা না হয় তবে সার্ভার কোনও কিছুকে বৈধতা না দিলে কোনও ক্রিয়াকে কীভাবে রিভার্ট করবেন?

একদম না. ক্লায়েন্ট শত্রুর হাতে। কোনও ক্রিয়াটি কীভাবে ফিরিয়ে আনতে হবে তা সম্পূর্ণরূপে নির্ভর করে যে আপনি কোনও ক্রিয়াটিকে কী হিসাবে বিবেচনা করছেন এবং এর প্রভাব কী হতে পারে। সবচেয়ে সহজ রুট হ'ল সার্ভারের অনুমতি না দেওয়া পর্যন্ত ক্রিয়াটি প্রয়োগ করা মোটেও নয় all কিছুটা কৌশলযুক্ত রুট হ'ল প্রতিটি ক্রিয়াটির ক্রিয়াটি পূর্বাবস্থায় ফিরিয়ে আনার ক্ষমতা রয়েছে এবং ক্লায়েন্টের সমস্ত অগ্রহণিত ক্রিয়াকে ক্যাশে করে তা নিশ্চিত করা। সার্ভার যখন তাদের স্বীকৃতি দেয় তখন তাদের ক্যাশে থেকে মুছুন। যদি কোনও পদক্ষেপ প্রত্যাখ্যান করা হয় তবে প্রতিটি ক্রিয়াকে বিপরীত ক্রমে রোলব্যাক করুন এবং এতে অস্বীকৃতিও রয়েছে including


1
আপনি এটি পেরেক দিয়েছিলেন। আপনি ডিবিএস +1 সিঙ্ক করার বিষয়ে ঠিক বলেছেন ক্লায়েন্টের নিজের কখনও ডিবি পরিবর্তন করা উচিত নয় ... কেবল সার্ভারে চলমান ফাংশনগুলি কল করুন এবং গেমটির যুক্তি ব্যবহার করে ডিবি আপডেট করুন, তারপরে ফলাফলগুলি পুনরুদ্ধার করুন।
কোয়েট

@ কাইলোটান: আমার মডেলটির প্রবাহকে নির্দেশ করার জন্য ধন্যবাদ
উমাইর

@ কাইলোটান: "সবচেয়ে সহজতম উপায় হ'ল আপনি স্থানান্তর করতে পারেন এমন একক ফাইল হিসাবে ডাটাবেস বাস্তবায়ন করা database এর অর্থ হ'ল প্রতিবার অ্যাপ্লিকেশন চালু হওয়ার সময় সমস্ত ডেটা ডাউনলোড হয়। কিছু জিনিস রয়েছে যা খুব ঘন ঘন পরিবর্তিত হয় এবং তাই এগুলি প্রতিবার ডাউনলোড করা গ্রহণযোগ্য হবে না। এটি অ্যাপের লঞ্চের সময়কেও যথেষ্ট পরিমাণে বাড়িয়ে তুলবে। কোন চিন্তা?
umair

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