রেকর্ড মেটাটাটা সঞ্চয় করার জন্য সেরা অনুশীলন

Question

ডাটাবেসে স্বতন্ত্র রেকর্ডগুলির মেটাডেটা সংরক্ষণ করার জন্য সেরা অনুশীলন কী?

আমার সাধারণ ডাটাবেসে অনেকগুলি সারণীর জন্য সর্বশেষ আপডেটের সময় ও সময় তৈরির মতো সাধারণ মেটা ডেটা সঞ্চয় করতে হবে। আমি কয়েকটি ভিন্ন সমাধান পেয়েছি:

1. মেটা ডেটা সরাসরি টেবিলগুলিতে সঞ্চয় করুন।

   পেশাদাররা:

   • মেটা ডেটা সরাসরি রেকর্ডের সাথে লিঙ্কযুক্ত
   • মেটা ডেটা পুনরুদ্ধার করতে কোনও যোগদানের প্রয়োজন নেই

   কনস:

   • প্রচুর নকল কলামের প্রয়োজন (উত্তরাধিকার ব্যবহার করা না হলে)
   • মেটা ডেটা এবং ব্যবসায়ের ডেটা আলাদা করা হয় না

2. সঠিক টেবিল এবং রেকর্ডগুলির সাথে ডেটা লিঙ্ক করতে নরম বিদেশী কী ব্যবহার করে একটি সাধারণ মেটা ডেটা টেবিল তৈরি করুন।

   পেশাদাররা:

   • কলামগুলির সদৃশ নেই
   • মেটা ডেটা ব্যবসায়ের ডেটা থেকে আলাদা করা হয়

   কনস:

   • মেটা ডেটা এবং ডেটার মধ্যে সরাসরি লিঙ্ক নেই (এফকে ব্যবহার করা যায় না)
   • যোগদানের জন্য একটি অতিরিক্ত শর্ত প্রয়োজন

3. প্রতিটি মেটা মেটা ডেটা প্রয়োজনের জন্য পৃথক মেটা ডেটা টেবিল তৈরি করুন।

   পেশাদাররা:

   • মেটা ডেটা সরাসরি রেকর্ডের সাথে লিঙ্কযুক্ত
   • মেটা ডেটা ব্যবসায়ের ডেটা থেকে আলাদা করা হয়

   কনস:

   • প্রচুর অতিরিক্ত টেবিলের প্রয়োজন
   • প্রচুর নকল কলামের প্রয়োজন (উত্তরাধিকার ব্যবহার করা না হলে)

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

Comments

আমরা কোন ধরণের মেটাডেটা নিয়ে কথা বলছি? একটি কলাম hstoreবা JSONকলাম ব্যবহার করা আপনার সমস্যার সমাধান করতে পারে?

— a_horse_with_no_name

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

— টিদো

তারপরে আমি এই তিনটি কলামটি বেস টেবিলটিতে যুক্ত না করার কোনও কারণ দেখতে পাচ্ছি না।

— a_horse_with_no_name

Answer 1

আপনি যে কলামগুলির কথা বলছেন তা 20 বাইট দখল করে (যদি প্যাডিং ছাড়া সারিবদ্ধ থাকে):

তৈরির সময়, আপডেটের সময় এবং উত্স উত্স

টাইমস্ট্যাম্প .. 8 বাইট
টাইমস্ট্যাম্প .. 8 বাইট
পূর্ণসংখ্যা .. 4 বাইট

পৃথক টেবিলের পৃথক সারির জন্য টিপল শিরোনাম এবং আইটেম পয়েন্টারটি 23 + 1 + 4 = 28 বাইটের সাথে প্রকৃত ডেটার 20 বাইট, এবং শেষে 4 বাইট প্যাডিং দখল করবে। প্রতি সারি 52 বাইট তৈরি করে । এখানে আরও পড়ুন:

• পড়ার পারফরম্যান্সের জন্য পোস্টগ্রিএসকিউএল কনফিগার করছে

স্টোরেজ সম্পর্কিত আপনার কাছে লাভের কিছুই নেই। পারফরম্যান্স সম্পর্কিত আপনি সারি প্রতি মাত্র 16 - 24 বাইট বেশি দিয়ে খুব কমই কিছু হারাবেন।

কলামগুলিও সরাসরি সারির অন্তর্ভুক্ত, তাই এগুলি একসাথে রাখাই বোঝা যায়। আমি সমস্ত প্রাসঙ্গিক টেবিলগুলিতে ঠিক এই জাতীয় কলামগুলি (শেষ আপডেটের জন্য পৃথক পৃথক উত্স) যুক্ত করার অভ্যাস তৈরি করি।

TRIGGER ON INSERT OR UPDATEএগুলি বর্তমান রাখার জন্য একটি লেখা আরও সহজ ।

দীর্ঘ গল্প সংক্ষিপ্ত: আপনার বিকল্প 1 এর জন্য শক্তিশালী ভোট ।

আমি যেখানে বিকল্প 3 তে যাব :
যদি মেটাডেটা প্রায়শই আপডেট হয় তবে মূল সারিটি হয় না। তারপরে এটি আপডেটের তুলনায় সস্তা এবং মূল টেবিলের ফোটা কমাতে একটি পৃথক 1: 1 টেবিল রাখার জন্য অর্থ দিতে পারে - অথবা এমনকি বিকল্প 2-এ যেতে পারে।

আমি যেখানে বিকল্প 2 তে যাব :
মেটাডেটা কলামগুলির সেটটি যদি পুনরাবৃত্তি হয়। প্রধান টেবিল (গুলি) এর মেটাডেটার সেটটিতে আপনার কাছে এফকে কলাম থাকতে পারে। আপনার উদাহরণের মতো তিনটি ছোট কলামের জন্য খুব বেশি সঞ্চয় করে না।

Comments

টেবিলের উত্তরাধিকারের সাথে এটি সমাধান করার বিষয়ে কী, সরাসরি টেবিলে মেটাডেটা কলম ব্যবহারের তুলনায় অসাধারণ ত্রুটি রয়েছে? তবে আমি যদি সঠিকভাবে বুঝতে পারি তবে পোস্টগ্রিসের টেবিলের উত্তরাধিকার এসকিউএল মানক নয়, তাই না?

— পঠিত

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

— এরউইন ব্র্যান্ডসটেটার