আমি প্রায় 8 বছর আগে একটি অ্যাপ্লিকেশানের জন্য এর মতো একটি সিস্টেম তৈরি করেছি এবং অ্যাপটির ব্যবহার বাড়ার সাথে সাথে এটি বিকশিত হয়ে উঠতে বেশ কয়েকটি উপায়ে ভাগ করতে পারি।
আমি কোনও পরিবর্তন থেকে "ইতিহাস" সারণীতে যে কোনও ডিভাইস থেকে প্রতিটি পরিবর্তন (সন্নিবেশ করানো, আপডেট করা বা মোছা) লগইন করে শুরু করেছি। সুতরাং, উদাহরণস্বরূপ, যদি কেউ "পরিচিতি" সারণিতে তাদের ফোন নম্বর পরিবর্তন করে, সিস্টেমটি যোগাযোগ.ফোন ক্ষেত্রটি সম্পাদনা করবে এবং ক্রিয়া = আপডেট, ফিল্ড = ফোন, রেকর্ড = [যোগাযোগ আইডি] সহ একটি ইতিহাস রেকর্ড যুক্ত করবে, মান = [নতুন ফোন নম্বর]। তারপরে যখনই কোনও ডিভাইস সিঙ্ক হয়, এটি সর্বশেষ সিঙ্কের পরে থেকে ইতিহাসের আইটেমগুলি ডাউনলোড করে এবং এটি তার স্থানীয় ডাটাবেসে প্রয়োগ করে। এটি উপরে বর্ণিত "লেনদেনের প্রতিলিপি" প্যাটার্নের মতো শোনাচ্ছে।
আইটেমগুলি বিভিন্ন ডিভাইসে তৈরি করা যেতে পারে তখন একটি বিষয় আইডিটিকে অনন্য রাখে। আমি এটি শুরু করার সময় ইউইউডিগুলি সম্পর্কে জানতাম না, তাই আমি স্বতঃবৃদ্ধি আইডি ব্যবহার করেছি এবং কিছু সংশোধিত কোড লিখেছিলাম যা ডিভাইস থেকে আপলোড হওয়া নতুন আইডি চেক করতে কেন্দ্রীয় সার্ভারে চলতে পারে, যদি কোনও বিরোধ হয় তবে তাদের একটি অনন্য আইডিতে পরিবর্তন করুন এবং উত্স ডিভাইসটিকে তার স্থানীয় ডাটাবেসে আইডি পরিবর্তন করতে বলুন। কেবলমাত্র নতুন রেকর্ডগুলির আইডি পরিবর্তন করা খুব খারাপ ছিল না, তবে আমি যদি উদাহরণস্বরূপ, যোগাযোগের সারণীতে একটি নতুন আইটেম তৈরি করি, তবে ইভেন্ট টেবিলে একটি নতুন সম্পর্কিত আইটেম তৈরি করুন, এখন আমার কাছে বিদেশী কী রয়েছে যা আমারও দরকার চেক এবং আপডেট।
অবশেষে আমি শিখেছি যে ইউইউডিগুলি এটি এড়াতে পারে তবে ততক্ষণে আমার ডাটাবেসটি বেশ বড় হয়ে উঠছিল এবং আমি ভয় পেয়েছিলাম যে পুরো ইউইউডি প্রয়োগের ফলে একটি পারফরম্যান্স সমস্যা তৈরি হবে। সুতরাং সম্পূর্ণ ইউআইডিগুলি ব্যবহার না করে আমি এলোমেলোভাবে উত্পন্ন, আইডি হিসাবে 8 টি অক্ষরের আলফানিউমারিক কীগুলি ব্যবহার শুরু করেছিলাম এবং বিরোধগুলি পরিচালনা করতে আমি আমার বিদ্যমান কোডটি রেখে দিয়েছি। আমার বর্তমান 8-চরিত্রের চাবি এবং কোনও ইউআইডি এর 36 টি অক্ষরের মধ্যে অবশ্যই একটি মিষ্টি স্পট থাকতে হবে যা অপ্রয়োজনীয় ফোলা ছাড়াই দ্বন্দ্বগুলি দূর করবে, তবে যেহেতু আমার কাছে ইতিমধ্যে দ্বন্দ্বের সমাধানের কোড রয়েছে, তাই এটির সাথে পরীক্ষার অগ্রাধিকার হয়নি hasn't ।
পরবর্তী সমস্যাটি হ'ল ইতিহাসের টেবিলটি ডাটাবেসের পুরো অংশের চেয়ে 10 গুণ বড় ছিল। এটি স্টোরেজ ব্যয়বহুল করে তোলে এবং ইতিহাসের টেবিলের যে কোনও রক্ষণাবেক্ষণ কষ্টদায়ক হতে পারে। পুরো টেবিলটি রাখার ফলে ব্যবহারকারীরা আগের কোনও পরিবর্তন ফিরিয়ে আনতে দেয়, তবে এটি ওভারকিলের মতো মনে হতে শুরু করে। সুতরাং আমি সিঙ্ক প্রক্রিয়াটিতে একটি রুটিন যুক্ত করেছি যেখানে কোনও ডিভাইস সর্বশেষ ডাউনলোড করা ইতিহাসের আইটেমটি যদি ইতিহাস টেবিলে আর উপস্থিত না থাকে তবে সার্ভার এটিকে সাম্প্রতিক ইতিহাসের আইটেম দেয় না, পরিবর্তে এটি সমস্ত ডেটাযুক্ত ফাইল দেয় gives যে অ্যাকাউন্ট। তারপরে আমি 90 দিনের পুরানো ইতিহাস আইটেমগুলি মুছতে একটি ক্রোনজব যুক্ত করেছি। এর অর্থ ব্যবহারকারীরা এখনও 90 দিনেরও কম পুরানো পরিবর্তনগুলি রোল করতে পারবেন এবং যদি তারা প্রতি 90 দিনে অন্তত একবার সিঙ্ক করেন তবে আপডেটগুলি আগের মতো বর্ধিত হবে। তবে যদি তারা 90 দিনের বেশি অপেক্ষা করে,
এই পরিবর্তন ইতিহাসের টেবিলের আকারটি প্রায় 90% হ্রাস করেছে, সুতরাং এখন ইতিহাসের সারণিটি বজায় রাখা কেবলমাত্র দশগুণের পরিবর্তে ডাটাবেসকে দ্বিগুণ করে তোলে। এই সিস্টেমের আরেকটি সুবিধা হ'ল প্রয়োজনের সাথে সিঙ্কিং হিস্ট্রি টেবিল ছাড়া এখনও কাজ করতে পারে - যেমন আমাকে অস্থায়ীভাবে অফলাইনে নিয়ে যাওয়া কিছু রক্ষণাবেক্ষণের প্রয়োজন হয়। অথবা আমি অ্যাকাউন্টের জন্য বিভিন্ন মূল্য পয়েন্টে বিভিন্ন রোলব্যাক সময়কাল অফার করতে পারি। এবং ডাউনলোড করতে যদি 90 দিনেরও বেশি পরিবর্তন হয় তবে সম্পূর্ণ ফাইলটি সাধারণত বর্ধিত বিন্যাসের চেয়ে বেশি দক্ষ।
যদি আমি আজ থেকে শুরু করতাম, আমি আইডি সংঘাতের চেকিং এড়িয়ে যাব এবং কেবলমাত্র যদি কিছু ক্ষেত্রে ত্রুটি পরীক্ষা করা হয় তবে দ্বন্দ্ব দূর করতে যথেষ্ট মূল দৈর্ঘ্যের লক্ষ্য রাখি। তবে ইতিহাসের সারণী এবং সাম্প্রতিক আপডেটগুলির জন্য বাড়তি ডাউনলোডগুলির সংমিশ্রণ বা প্রয়োজনের সময় একটি সম্পূর্ণ ডাউনলোড ভাল কাজ করছে।