একটি মোবাইল ক্লায়েন্ট এবং একটি সার্ভারের মধ্যে রেফারেন্সিয়াল অখণ্ডতা বজায় রাখা

Question

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

Comments

ওভার-আর্চিং ধারণাটি হ'ল ক্লায়েন্টটি ওয়েব সার্ভারের জন্য ক্যাশে হিসাবে কাজ করে, ক্লায়েন্টে পরিবর্তন তৈরি হয়, তারপরে ওয়েব সার্ভারে ঠেলা যায়

— জো কর্টোপ্যাসি

Answer 1

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

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

সন্নিবেশগুলি ট্র্যাক করতে আপনার সারিগুলিতে একটি তৈরি টাইমস্ট্যাম্প প্রয়োজন। আপডেটগুলি ট্র্যাক করতে আপনার সারিগুলিতে একটি লাস্টআপডেট টাইমস্ট্যাম্প ট্র্যাক করতে হবে। মুছে ফেলা ট্র্যাক করতে আপনার একটি সমাধিক্ষেত্র টেবিল প্রয়োজন।

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

মাইক্রোসফ্ট সিঙ্ক ফ্রেমওয়ার্কের মতো এই ধরণের জিনিস পরিচালনা করার জন্য ফ্রেমওয়ার্ক রয়েছে ।

Comments

সিঙ্ক ফ্রেমওয়ার্কটি এখনও জীবিত

— সাদাকাত

Answer 2

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

এর জন্য দুটি অনুশীলন রয়েছে:

একটি হ'ল ক্লায়েন্টের উপর "অস্থায়ী" রেকর্ড তৈরি করা এবং তারপরে আপনি এগুলি সার্ভারের সাথে সিঙ্ক করার সময় কেন্দ্রীয় সিস্টেমটি আইডি নির্ধারণ করুন। এটি প্রতিফলিত করতে ক্লায়েন্ট স্থানীয় রেকর্ডটি আপডেট করতে পারে।

অন্যটি হল আপনি আইডি তৈরির পদ্ধতি এমনভাবে বিতরণ করুন যাতে (সাধারণত সম্ভাব্যভাবে) ক্লায়েন্টরা সংঘর্ষ ছাড়াই আইডি তৈরি করতে দেয়।

তার জন্য, ইউআইডিগুলিতে যান - ভি 4 এর সংঘর্ষের পক্ষে মোটামুটি সম্ভাবনা নেই।

অন্যথায়, এমন কিছু বিবেচনা করুন যা রেকর্ড আইডিতে অনন্য মোবাইল ডিভাইস আইডি রাখে। সুতরাং, আপনার রেকর্ড আইডি ${imei}-${local sequence number}বা অন্য কোনও কিছু হতে পারে , যেখানে আইএমইআই স্বাতন্ত্র্যতা নিশ্চিত করে এবং স্থানীয় সিকোয়েন্স নম্বরটি কেবলমাত্র একটি সাধারণ ক্রমযুক্ত ডাটাবেস আইডি।

Answer 3

ড্যানিয়েল পিটম্যানের উত্তর ছাড়াও , সার্ভারের পক্ষে একটি সম্ভাবনা হ'ল প্রতিটি ক্লায়েন্টকে একটি অনন্য ক্লায়েন্ট আইডি অর্পণ করা এবং ক্লায়েন্ট আইডিটিকে প্রাথমিক কীটির অংশ করা।

Answer 4

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

Local Table            Remote Table

_id (used locally)
remote_id ------------- id
name      ------------- name

ক্লায়েন্ট অ্যাপ্লিকেশনটিতে আমি _id ক্ষেত্রের দ্বারা টেবিলগুলি সংযুক্ত করি, আমি দূরবর্তী অবস্থান থেকে ডেটা আনতে, যোগদান করতে, ইত্যাদি করতে দূরবর্তী আইডি ক্ষেত্রটি ব্যবহার করি ..

স্থানীয়ভাবে উদাহরণ:

Local Client Table       Local ClientType Table      Local ClientType
                         _id
                         remote_id  
_id -------------------- client_id
remote_id                client_type_id -------------- _id
                                                      remote_id
name                    name                          name

দূরবর্তী উদাহরণ:

Remote Client Table      Remote ClientType Table      Remote ClientType
id -------------------- client_id
                        client_type_id -------------- id
name                    name                          name

এই পরিস্থিতিটি এবং কোডটিতে কোনও যৌক্তিক ছাড়াই ডেটা অখণ্ডতা ব্যর্থতার কারণ হতে পারে, কারণ ক্লায়েন্ট_ টাইপ টেবিলটি স্থানীয় বা দূরবর্তী টেবিলের সাথে সত্যিকারের আইডির সাথে মেলে না, স্থানীয় _id ক্ষেত্রটি আপডেট করতে বলছে, এটি প্রভাবিত টেবিলগুলি আপডেট করে স্ক্লাইটে আগের তৈরি ট্রিগারটিকে আগুন ধরিয়ে দেয়। http://www.sqlite.org/lang_createtrigger.html

1- রিমোট_আইডি সার্ভারে উত্পন্ন হয়

2- ক্লায়েন্টকে একটি সংকেত প্রদান করে

3- ক্লায়েন্ট তার _আইডি ক্ষেত্রটি আপডেট করে এবং একটি ট্রিগার চালিত করে যা স্থানীয় _ID তে যোগদানকারী স্থানীয় টেবিলগুলি আপডেট করে

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