সংস্করণ একটি ডাটাবেসের বিষয়বস্তু নিয়ন্ত্রণ করে


16

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

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

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

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

এখানে সেরা পদ্ধতির কি? আমার নিজের ঘূর্ণায়মান দেখে মনে হচ্ছে আমি সম্ভবত অন্য কারও (আরও ভাল) কোডবেস পুনরায় উদ্ভাবন করছি।


PostgreSQL এর জন্য বোনাস পয়েন্ট।


এই প্রশ্নটি ইতিমধ্যে এসও: স্ট্যাকওভারফ্লো / প্রশ্ন / 3874199/… এ আলোচনা করা হয়েছে । "ডাটাবেস রেকর্ড ইতিহাস" এর জন্য গুগল এবং আপনি আরও কিছু নিবন্ধ পাবেন।
ডক ব্রাউন


কৌশলটি করতে এসকিউএল-সার্ভারের লেনদেন লগটি ব্যবহার করছেন না কেন?
থমাস জাঙ্ক

উত্তর:


11

আমি সাধারণত যে কৌশলটি ব্যবহার করেছি তা হ'ল শেষ রেকর্ডের ক্ষেত্র সহ সম্পূর্ণ রেকর্ডটি সংরক্ষণ করা। একটি ব্যবসায়ের নিয়ম রয়েছে যে কেবলমাত্র একটি সারিতে নাল এন্ড টাইমস্ট্যাম্প থাকতে পারে এবং এটি অবশ্যই বর্তমানে সক্রিয় সামগ্রী।

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

আপনি একেবারে সঠিক যে প্রচুর ছোট্ট পরিবর্তনগুলি ব্লোট তৈরি করবে, তবে কোড এবং রিপোর্টিং সরলতার বিরুদ্ধে আপনার এটিকে বাণিজ্য করতে হবে।


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

প্রকৃত টাইমস্ট্যাম্প ব্যবহার করা অনিরাপদ, তবে কিছু এমভিসিসি ডাটাবেস টিপলস সহ ন্যূনতম এবং সর্বাধিক লেনদেনের সিরিয়াল নম্বরগুলি সংরক্ষণ করে অভ্যন্তরীণভাবে কাজ করে।
ব্যবহারকারী 2313838

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

@ জিরাট এটি অনেক বছর পরে যেহেতু আমি এমন একটি ডেটাবেস তৈরি করেছি যেটির এই প্রয়োজনীয়তা ছিল এবং আমার আর সেই ডাটাবেসটিতে অ্যাক্সেস নেই। আপনি ঠিক বলেছেন যে একটি স্ট্যান্ডার্ড অনন্য সূচক একাধিক নালকে সমর্থন করতে পারে তবে আমি মনে করি আমরা একটি অনন্য বাধা বা সম্ভবত কার্যকরী সূচক ব্যবহার করেছি।
কিউইরন

8

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

হুডের নীচে যা ঘটে তা হ'ল:

  • সিডিসি একটি অতিরিক্ত সারণী তৈরি করে যার সংশোধনগুলি রয়েছে,

  • আপনার আসল টেবিলটি আগের মতো ব্যবহৃত হয়েছিল, এটিই কোনও আপডেট এই টেবিলটিতে সরাসরি প্রতিফলিত হয়,

  • সিডিসি টেবিলটি কেবল পরিবর্তিত মান সংরক্ষণ করে, যার অর্থ ডেটা ডুপ্লিকেশনটি সর্বনিম্ন রাখা হয়।

পরিবর্তনগুলি অন্য একটি সারণীতে সংরক্ষণ করা হয় তার দুটি বড় পরিণতি ঘটে:

  • মূল টেবিল থেকে নির্বাচনগুলি সিডিসি ছাড়াই তত দ্রুত। আমি যদি ভালভাবে মনে রাখি, আপডেটের পরে সিডিসি ঘটে , তাই আপডেটগুলিও সমান দ্রুত হয় (যদিও সিডিসি কীভাবে ডেটা ধারাবাহিকতা পরিচালনা করে তা আমি ভালভাবে মনে করি না)।

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


6

"দার্শনিকভাবে" এবং কোডটিতে প্রথমে সমস্যার সমাধান করুন। এবং তারপরে কোডটি এবং ডাটাবেসের সাথে "আলাপচারিতা" করুন যাতে এটি ঘটে যায়।

উদাহরণস্বরূপ , যদি আপনি জেনেরিক নিবন্ধগুলি নিয়ে কাজ করে থাকেন তবে কোনও নিবন্ধের জন্য প্রাথমিক ধারণাটি দেখতে এরকম হতে পারে:

class Article {
  public Int32 Id;
  public String Body;
}

এবং পরবর্তী সবচেয়ে বেসিক স্তরে, আমি সংশোধনগুলির একটি তালিকা রাখতে চাই:

class Article {
  public Int32 Id;
  public String Body;
  public List<String> Revisions;
}

এবং এটি আমার উপর ভোর হতে পারে যে বর্তমানের দেহটি কেবল সর্বশেষ সংশোধন। এবং এর অর্থ দুটি জিনিস: আমার প্রতিটি সংশোধনীর তারিখ বা নম্বর দেওয়া দরকার:

class Revision {
  public Int32 Id;
  public Article ParentArticle;
  public DateTime Created;
  public String Body;
}

এবং ... এবং নিবন্ধের বর্তমান বডিটি সর্বশেষ সংশোধন থেকে আলাদা হওয়ার দরকার নেই:

class Article {
  public Int32 Id;
  public String Body {
    get {
      return (Revisions.OrderByDesc(r => r.Created))[0];
    }
    set {
      Revisions.Add(new Revision(value));
    }
  }
  public List<Revision> Revisions;
}

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

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

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

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


2

নিরীক্ষণ ট্র্যাকিং ট্রিগারটির জন্য একটি পোস্টগ্রাসএসকিউএল উইকি পৃষ্ঠা রয়েছে যা আপনাকে কীভাবে নিরীক্ষণ লগ সেট আপ করতে পারে যা আপনাকে যা করবে তা করবে।

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

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

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


1

ঠিক আছে, আমি স্রেফ সহজ বিকল্পটি দিয়ে যাচ্ছি, এটি একটি ট্রিগার যা প্রতি সারণির ইতিহাস লগতে সারিটির পুরানো সংস্করণটি অনুলিপি করে।

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

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

যাইহোক, এটি সব এখানে গিথুব এ ।

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