লুকানো রত্ন:ActiveRecord স্টোর

রেল হল একটি বৃহৎ ফ্রেমওয়ার্ক যার সাথে নির্দিষ্ট পরিস্থিতিতে অনেক সহজ বিল্ট-ইন টুল রয়েছে। এই সিরিজে, আমরা রেলের বৃহৎ কোডবেসে লুকানো কিছু স্বল্প-পরিচিত সরঞ্জামের দিকে নজর দেব৷

এই নিবন্ধে, আমরা ActiveRecord-এর store-এ ফোকাস করব এবং store_accessor পদ্ধতি এই উভয় পদ্ধতিরই উদ্দেশ্য JSON বা YAML-এর মতো ডাটাবেস কলামে স্ট্রাকচার্ড ডেটা সংরক্ষণ করার ক্ষেত্রে। যখন store_accessor গেটার পদ্ধতি, store সহ কোনও মডেল আটকে না রেখে এই ডেটা থেকে মানগুলি দখল করার একটি সহজ উপায় আমাদের দেয় আরও এক ধাপ এগিয়ে যায় এবং স্বচ্ছভাবে আমাদের নির্বাচিত বিন্যাসে ডেটা সিরিয়ালাইজ/ডিসারিয়ালাইজ করে। এটি কোথায় উপযোগী হতে পারে তা বোঝার জন্য, আমরা রিলেশনাল ডাটাবেসে JSON সংরক্ষণ করার বিকল্পগুলি এবং আপনি এটি করতে চাইতে পারেন এমন কিছু কারণও দেখব৷

ডেটাবেসে JSON

আমার স্পষ্ট করা উচিত যে যখন আমি এই নিবন্ধে 'ডাটাবেস' বলি, তখন আমি রিলেশনাল ডেটাবেসগুলি উল্লেখ করছি, বিশেষ করে PostgreSQL এবং MySQL, কারণ সেগুলি রেল সম্প্রদায়ে সবচেয়ে বেশি ব্যবহৃত হয়৷

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

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

JSON বনাম JSONB

PostgreSQL এর দুই ধরনের JSON কলাম আছে:json এবং jsonb . প্রধান পার্থক্য হল jsonb লেখার সময় পার্স করা হয়, যার অর্থ ডেটাবেস দ্রুত অনুসন্ধান করতে পারে এমন একটি বিন্যাসে ডেটা সংরক্ষণ করা হয়। সতর্কতা হল যে JSON ইতিমধ্যে পার্স করা হয়েছে, যখন টেক্সট হিসাবে আউটপুট করা হয়, তখন ব্যবহারকারী যা লিখেছেন তা আর ঠিক মেলে না। উদাহরণস্বরূপ, ডুপ্লিকেট কীগুলি সরানো হতে পারে বা মূল ক্রমটি মূলের সাথে নাও মিলতে পারে৷

৷

PostgreSQL ডকুমেন্টেশন বলে যে বেশিরভাগ ক্ষেত্রে, jsonb আপনি যা চান তা যদি না আপনার কাছে একটি নির্দিষ্ট কারণ থাকে।

MySQL এর json কলাম jsonb এর অনুরূপ আচরণ করে PostgreSQL-এ। 'ব্যবহারকারী যা প্রবেশ করেছে' আউটপুটকে সমর্থন করতে, আপনাকে সম্ভবত একটি varchar ব্যবহার করতে হবে কলাম বা অনুরূপ কিছু।

JSON বনাম পাঠ্য

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

রেলের মধ্যে JSON কলাম

রেলের json তৈরির জন্য সমর্থন রয়েছে (এবং jsonb পোস্টগ্রেএসকিউএল-এ) মাইগ্রেশনে কলাম:

class CreateItems < ActiveRecord::Migration[7.0]
  def change
    create_table :items do |t|
      t.jsonb :user_attributes

    ...
    end
  end
end

এই কলামটি পড়ার সময়, ফিরে আসা ফলাফল একটি হ্যাশ:

> Item.first.user_attributes
  Item Load (0.6ms)  SELECT "items".* FROM "items" ORDER BY "items"."id" ASC LIMIT $1  [["LIMIT", 1]]
=> {"color"=>"text-red-400"}
> Item.first.update!(user_attributes: {color: "text-blue-400"})
> Item.first.user_attributes.dig(:color)
=> "text-blue-400"

এখন যেহেতু আমাদের একটি হ্যাশ বৈশিষ্ট্য রয়েছে, আপনি মানগুলি পড়তে/লিখতে মডেলটিতে কিছু সহায়ক পদ্ধতি যুক্ত করতে প্রলুব্ধ হতে পারেন:

class Item < ApplicationRecord
  def color=(value)
    self.user_attributes["color"] = value
  end

  def color
    user_attributes.dig("color")
  end
end

এই পদ্ধতিগুলি পুরোপুরি ভালভাবে কাজ করে তবে আপনার যদি মোকাবেলা করার জন্য প্রচুর JSON কী থাকে তবে দ্রুত অপ্রয়োজনীয় হয়ে উঠতে পারে; সৌভাগ্যবশত, রেল আমাদের কভার করেছে।

ActiveRecords এর দোকান এবং store_accessor

ডাটাবেসে JSON সংরক্ষণের দুটি দিক রয়েছে:সিরিয়ালাইজেশন এবং অ্যাক্সেস। আপনি যদি একটি json ব্যবহার করেন - আপনার ডাটাবেসে কলাম টাইপ করুন, তারপর আপনাকে সিরিয়ালাইজেশন দিক সম্পর্কে চিন্তা করতে হবে না। রেল এবং ডাটাবেস অ্যাডাপ্টার আপনার জন্য এটি পরিচালনা করবে (আপনি সরাসরি store_accessor এ যেতে পারেন ) আপনি যদি একটি পাঠ্য কলামে ডেটা সংরক্ষণ করেন, তাহলে ActiveRecord এর store পদ্ধতিটি আপনার জন্য, যা নিশ্চিত করে যে আপনি কলামে যে ডেটা লিখছেন তা আপনার নির্বাচিত বিন্যাসে সিরিয়ালাইজ করা হয়েছে৷

ActiveRecords এর দোকান

ActiveRecord এর একটি store আছে আমরা আমাদের কলামে যে ডেটা পড়ি বা লিখি তা স্বয়ংক্রিয়ভাবে সিরিয়ালাইজ করার পদ্ধতি:

class Item < ApplicationRecord
  store :user_attributes, accessors: [:color], coder: JSON
end

এখানে, :user_attributes accessors করার সময় আমরা যে কলামটি ব্যবহার করতে চাই এটি হল কীগুলির তালিকা যা আমরা অ্যাক্সেস করতে চাই (শুধু color আমাদের ক্ষেত্রে এখানে), এবং সবশেষে, আমরা উল্লেখ করি কিভাবে আমরা ডেটা এনকোড করতে চাই। আমরা JSON ব্যবহার করছি, কিন্তু YAML বা কাস্টম এনকোডিংয়ের মতো জিনিসগুলি সহ আপনি এখানে আপনার পছন্দের যেকোনো কিছু ব্যবহার করতে পারেন। এই পদ্ধতিটি কেবল সিরিয়ালাইজেশন পরিচালনা করে (আপনার নির্বাচিত কোডারের সাথে) এবং কল করে store_accessor হুডের নিচে।

ActiveRecords এর স্টোর_অ্যাকসেসর

আমরা store_accessor ব্যবহার করে আমাদের মডেলে get/set পদ্ধতি তৈরি করি :

class Item < ApplicationRecord
  store_accessor :user_attributes, :color
  store_accessor :user_attributes, :name, prefix: true
  store_accessor :user_attributes, :location, prefix: 'primary'
end

এখানে আবার, user_attributes আমরা যে ডাটাবেস কলামটি ব্যবহার করতে চাই, তার পরে আমরা JSON ডেটাতে যে কী ব্যবহার করতে চাই, এবং শেষ পর্যন্ত, আমাদের কাছে একটি উপসর্গ (বা প্রত্যয়) ব্যবহার করার বিকল্প আছে। মনে রাখবেন যে store_accessor নেস্টেড ডেটা সমর্থন করে না, শুধুমাত্র শীর্ষ-স্তরের কী-মান জোড়া। prefix এবং suffix বিকল্পগুলি হয় একটি বুলিয়ান, স্ট্রিং বা প্রতীক নেয়। যদি একটি বুলিয়ান true পাস করা হয়, তারপর কলামের নামটি উপসর্গ/প্রত্যয় হিসাবে ব্যবহৃত হয়।

=>item = Item.create!(color: 'red', user_attributes_name: 'Jonathan', primary_location: 'New Zealand')
>#<Item:0x000055d63f4f0360
 id: 4,
 user_attributes: {"color"=>"red", "name"=>"Jonathan", "location"=>"New Zealand"}>
=>item.color
>"red"
=> item.user_attributes_name
>"Jonathan"
=> item.name
>NoMethodError: undefined method `name'...
=> item.primary_location
>"New Zealand"

বাস্তব-বিশ্ব ব্যবহার

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

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

আমি কাজ করছি একটি পার্শ্ব প্রকল্প ব্যবহারকারীদের ব্যবহারকারী-সংজ্ঞায়িত বৈশিষ্ট্য সহ আইটেমগুলিতে স্বেচ্ছাচারী বৈশিষ্ট্য সেট করার অনুমতি দেওয়ার জন্য JSON স্টোরেজ ব্যবহার করে। এই ডেটার তরল এবং অপ্রত্যাশিত প্রকৃতির কারণে, JSON স্টোরেজের মতো কিছু (store_accessor সহ পরিচিত বৈশিষ্ট্যের জন্য s) একটি প্রাকৃতিক উপযুক্ত।

সারাংশ

JSON ডেটা (এবং ActiveRecord এর আশেপাশে সাহায্যকারী) খুব দরকারী হতে পারে যখন ডেটা এবং ডেটা কাঠামো পরিবর্তনযোগ্য বা অজানা হয়। অবশ্যই, এই ধরনের ডেটা স্টোরেজ, বেশিরভাগ জিনিসের মতো, একটি ট্রেড-অফ। যখন আপনি নির্দিষ্ট রেকর্ডের জন্য ডেটা কাঠামোতে অনেক নমনীয়তা পান, আপনি ডেটাবেসের সীমাবদ্ধতা আপনাকে দিতে পারে এমন কিছু ডেটা অখণ্ডতা ছেড়ে দেন। এছাড়াও আপনি সাধারণ ActiveRecord ক্যোয়ারী, যোগদান ইত্যাদির মাধ্যমে রেকর্ড জুড়ে অনুসন্ধান করার ক্ষমতা কমিয়ে দেন।

এখানে কিছু নিয়ম-কানুন রয়েছে, যদি আপনি:

জেনে রাখুন যে JSON কীগুলি সমস্ত সারির জন্য একই হবে, বা
অন্য কোনো ডাটাবেস টেবিলের আইডি (প্রাথমিক কী) সংরক্ষণ করছে, অথবা
জেএসএন-এ একটি টেবিল থেকে একটি রেকর্ড খুঁজতে ব্যবহৃত একটি মান সঞ্চয় করছে

তারপরে, আপনি একটি নতুন টেবিল তৈরি করা ভাল হতে পারে যা আপনার জন্য ডেটা অখণ্ডতা প্রয়োগ করতে ডাটাবেসকে ব্যবহার করতে পারে। যাইহোক, আপনি যদি সারি-নির্দিষ্ট ডেটা সঞ্চয় করেন যা সরাসরি অন্যান্য টেবিলের সাথে সম্পর্কিত নয়, তাহলে JSON আপনাকে আপনার ডাটাবেস গঠনকে সহজ করতে সাহায্য করতে পারে।