ActiveRecord बनाम एक्टोपार्ट वन

डेटा अधिकांश सॉफ़्टवेयर अनुप्रयोगों का एक मुख्य भाग है। एक डेटाबेस से डेटा को मैप करना और क्वेरी करना एक डेवलपर के जीवन में एक आवर्ती कार्य है। इस वजह से, प्रक्रिया को समझना और कार्य को सरल बनाने वाले अमूर्त का उपयोग करने में सक्षम होना महत्वपूर्ण है।

इस पोस्ट में, दो की श्रृंखला में से पहला, आपको ActiveRecord (रूबी) और एक्टो (अमृत) के बीच तुलना मिलेगी। हम देखेंगे कि कैसे दोनों टूल डेवलपर्स को डेटाबेस स्कीमा को माइग्रेट करने और मैप करने में सक्षम बनाते हैं।

तो हम सेब और संतरे की तुलना करेंगे। (मूल) बैटगर्ल, जिसे कभी एक शब्द कहने की ज़रूरत नहीं पड़ी, बनाम बैटमैन, स्पष्ट रूप से 'आई एम बैटमैन' बताते हुए। निहित, विन्यास पर सम्मेलन, बनाम स्पष्ट इरादा। एक दौर। लड़ो!

ActiveRecord

इसकी रिलीज के 10 से अधिक वर्षों के साथ, संभावना है, आपने पहले ही ActiveRecord के बारे में सुना है - प्रसिद्ध ओआरएम जिसे रूबी ऑन रेल्स प्रोजेक्ट्स के साथ डिफ़ॉल्ट रूप से भेज दिया जाता है।

ActiveRecord एमवीसी में एम है - मॉडल - जो व्यापार डेटा और तर्क का प्रतिनिधित्व करने के लिए जिम्मेदार प्रणाली की परत है। ActiveRecord व्यावसायिक वस्तुओं के निर्माण और उपयोग की सुविधा प्रदान करता है जिनके डेटा को डेटाबेस में लगातार भंडारण की आवश्यकता होती है। यह ActiveRecord पैटर्न का एक कार्यान्वयन है जो स्वयं, ऑब्जेक्ट रिलेशनल मैपिंग सिस्टम का विवरण है।

हालांकि यह ज्यादातर रेल के साथ उपयोग करने के लिए जाना जाता है, ActiveRecord को एक स्टैंडअलोन टूल के रूप में भी इस्तेमाल किया जा सकता है, अन्य परियोजनाओं में एम्बेड किया जा सकता है।

एक्टो

ActiveRecord की तुलना में, Ecto एक बिल्कुल नया (और इस समय उतना प्रसिद्ध नहीं) टूल है। यह अमृत में लिखा गया है और फीनिक्स परियोजनाओं में डिफ़ॉल्ट रूप से शामिल है।

ActiveRecord के विपरीत, Ecto एक ORM नहीं है, बल्कि एक पुस्तकालय है जो Elixir के उपयोग को क्वेरी लिखने और डेटाबेस के साथ बातचीत करने में सक्षम बनाता है।

एक्टो एलिक्सिर में क्वेरी लिखने और डेटाबेस के साथ बातचीत करने के लिए एक डोमेन विशिष्ट भाषा है।

डिजाइन के अनुसार, एक्टो एक स्टैंडअलोन टूल है, जिसका उपयोग विभिन्न अमृत परियोजनाओं में किया जा रहा है और किसी भी ढांचे से जुड़ा नहीं है।

क्या आप सेब और संतरे की तुलना नहीं कर रहे हैं?

हाँ हम! हालाँकि ActiveRecord और Ecto शब्दार्थ रूप से भिन्न हैं, लेकिन डेटाबेस माइग्रेशन, डेटाबेस मैपिंग, क्वेरीज़ और सत्यापन जैसी सामान्य सुविधाएँ ActiveRecord और Ecto दोनों द्वारा समर्थित हैं। और हम दोनों साधनों का उपयोग करके समान परिणाम प्राप्त कर सकते हैं। रूबी पृष्ठभूमि से आने वाले अमृत में रुचि रखने वालों के लिए हमने सोचा कि यह एक दिलचस्प तुलना होगी।

चालान प्रणाली

शेष पोस्ट के दौरान, प्रदर्शन के लिए एक काल्पनिक चालान प्रणाली का उपयोग किया जाएगा। आइए कल्पना करें कि हमारे पास सुपर हीरो को सूट बेचने वाला एक स्टोर है। चीजों को सरल रखने के लिए, हमारे पास इनवॉइस सिस्टम के लिए केवल दो टेबल होंगे:उपयोगकर्ता और चालान ।

नीचे उन तालिकाओं की संरचना, उनके क्षेत्रों और प्रकारों के साथ है:

उपयोगकर्ता

चालान

उपयोगकर्ता तालिका में चार फ़ील्ड हैं:full_name , ईमेल , updated_at और चौथा क्षेत्र जो उपयोग किए गए उपकरण पर निर्भर है। ActiveRecord एक created_at . बनाता है फ़ील्ड जबकि Ecto एक insert_at . बनाता है उस समय के टाइमस्टैम्प का प्रतिनिधित्व करने के लिए फ़ील्ड, जब रिकॉर्ड पहली बार डेटाबेस में डाला गया था।

दूसरी तालिका का नाम चालान . है . इसके पांच क्षेत्र हैं:user_id , भुगतान_विधि , paid_at , updated_at और, उपयोगकर्ता तालिका के समान, या तो created_at या insert_at , उपयोग किए गए टूल के आधार पर।

उपयोगकर्ता और इनवॉइस तालिका में निम्नलिखित संबद्धताएं हैं:

• एक उपयोगकर्ता के पास कई चालान होते हैं
• एक चालान उपयोगकर्ता का होता है

माइग्रेशन

माइग्रेशन डेवलपर्स को एक पुनरावृत्त प्रक्रिया का उपयोग करके समय के साथ अपने डेटाबेस स्कीमा को आसानी से विकसित करने की अनुमति देता है। ActiveRecord और Ecto दोनों ही डेवलपर्स को SQL से सीधे निपटने के बजाय एक उच्च-स्तरीय भाषा (क्रमशः रूबी और अमृत) का उपयोग करके डेटाबेस स्कीमा को माइग्रेट करने में सक्षम बनाते हैं।

आइए एक नज़र डालते हैं कि कैसे माइग्रेशन ActiveRecord और Ecto में उपयोगकर्ता और इनवॉइस टेबल बनाने के लिए उपयोग करके काम करते हैं।

ActiveRecord:उपयोगकर्ता तालिका बनाना

माइग्रेशन

class CreateUsers < ActiveRecord::Migration[5.2]
  def change
    create_table :users do |t|
      t.string :full_name, null: false
      t.string :email, index: {unique: true}, null: false
      t.timestamps
    end
  end
end

ActiveRecord माइग्रेशन create_table . का उपयोग करके तालिकाओं के निर्माण को सक्षम बनाता है तरीका। हालांकि created_at और updated_at माइग्रेशन फ़ाइल में फ़ील्ड परिभाषित नहीं हैं, t.timestamps . का उपयोग दोनों को बनाने के लिए ActiveRecord को ट्रिगर करता है।

टेबल संरचना बनाई गई

CreateUsers . चलाने के बाद माइग्रेशन, बनाई गई तालिका में निम्न संरचना होगी:

   Column   |            Type             | Nullable |              Default
------------+-----------------------------+----------+-----------------------------------
 id         | bigint                      | not null | nextval('users_id_seq'::regclass)
 full_name  | character varying           | not null |
 email      | character varying           | not null |
 created_at | timestamp without time zone | not null |
 updated_at | timestamp without time zone | not null |
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
    "index_users_on_email" UNIQUE, btree (email)

माइग्रेशन ईमेल फ़ील्ड के लिए एक अद्वितीय अनुक्रमणिका बनाने के लिए भी ज़िम्मेदार है। विकल्प index: {unique: true} ईमेल फ़ील्ड परिभाषा को पास किया जाता है। यही कारण है कि तालिका ने "index_users_on_email" UNIQUE, btree (email) को सूचीबद्ध किया है इसकी संरचना के हिस्से के रूप में अनुक्रमणिका।

एक्टो:उपयोगकर्ता तालिका बनाना

माइग्रेशन

defmodule Financex.Repo.Migrations.CreateUsers do
  use Ecto.Migration
 
  def change do
    create table(:users) do
      add :full_name, :string, null: false
      add :email, :string, null: false
      timestamps()
    end
 
    create index(:users, [:email], unique: true)
  end
end

एक्टो माइग्रेशन create() . फंक्शन को जोड़ती है और table() उपयोगकर्ता तालिका बनाने के लिए। एक्टो माइग्रेशन फ़ाइल अपने ActiveRecord समकक्ष के समान है। ActiveRecord में टाइमस्टैम्प फ़ील्ड (created_at और updated_at ) t.timestamps . द्वारा बनाए गए हैं Ecto में रहते हुए टाइमस्टैम्प फ़ील्ड (inserted_at और updated_at ) timestamps() . द्वारा बनाए जाते हैं समारोह।

अनुक्रमणिका कैसे बनाई जाती है, इस पर दोनों उपकरणों के बीच एक छोटा सा अंतर है। ActiveRecord में, अनुक्रमणिका को बनाए जा रहे फ़ील्ड के विकल्प के रूप में परिभाषित किया गया है। Ecto कार्यों के संयोजन का उपयोग करता है create() और index() इसे प्राप्त करने के लिए, तालिका बनाने के लिए संयोजन का उपयोग कैसे किया जाता है, इसके अनुरूप।

टेबल संरचना बनाई गई

   Column    |            Type             | Nullable |              Default
-------------+-----------------------------+----------+-----------------------------------
 id          | bigint                      | not null | nextval('users_id_seq'::regclass)
 full_name   | character varying(255)      | not null |
 email       | character varying(255)      | not null |
 inserted_at | timestamp without time zone | not null |
 updated_at  | timestamp without time zone | not null |
Indexes:
    "users_pkey" PRIMARY KEY, btree (id)
    "users_email_index" UNIQUE, btree (email)

Financex.Repo.Migrations.CreateUsers . चलाने पर बनाई गई तालिका माइग्रेशन में ActiveRecord का उपयोग करके बनाई गई तालिका के समान संरचना होती है।

ActiveRecord:invoices बनाना टेबल

माइग्रेशन

class CreateInvoices < ActiveRecord::Migration[5.2]
  def change
    create_table :invoices do |t|
      t.references :user
      t.string :payment_method
      t.datetime :paid_at
      t.timestamps
    end
  end
end

इस माइग्रेशन में t.references . शामिल हैं विधि, जो पिछले एक में मौजूद नहीं थी। इसका उपयोग उपयोगकर्ता तालिका का संदर्भ बनाने के लिए किया जाता है। जैसा कि पहले बताया गया है, एक उपयोगकर्ता के पास कई चालान होते हैं और एक चालान उपयोगकर्ता का होता है। t.references विधि एक user_id बनाता है उस संदर्भ को रखने के लिए चालान तालिका में कॉलम।

टेबल संरचना बनाई गई

     Column     |            Type             | Nullable |               Default
----------------+-----------------------------+----------+--------------------------------------
 id             | bigint                      | not null | nextval('invoices_id_seq'::regclass)
 user_id        | bigint                      |          |
 payment_method | character varying           |          |
 paid_at        | timestamp without time zone |          |
 created_at     | timestamp without time zone | not null |
 updated_at     | timestamp without time zone | not null |
Indexes:
    "invoices_pkey" PRIMARY KEY, btree (id)
    "index_invoices_on_user_id" btree (user_id)

बनाई गई तालिका पहले बनाई गई तालिका के समान पैटर्न का अनुसरण करती है। अंतर केवल एक अतिरिक्त अनुक्रमणिका (index_invoices_on_user_id .) का है ), जिसे ActiveRecord स्वचालित रूप से तब जोड़ता है जब t.references विधि का उपयोग किया जाता है।

एक्टो:invoices बनाना टेबल

माइग्रेशन

defmodule Financex.Repo.Migrations.CreateInvoices do
  use Ecto.Migration
 
  def change do
    create table(:invoices) do
      add :user_id, references(:users)
      add :payment_method, :string
      add :paid_at, :utc_datetime
      timestamps()
    end
 
    create index(:invoices, [:user_id])
  end
end

Ecto references() . का उपयोग करके डेटाबेस संदर्भों के निर्माण का भी समर्थन करता है समारोह। ActiveRecord के विपरीत, जो कॉलम नाम का अनुमान लगाता है, Ecto को डेवलपर को user_id को स्पष्ट रूप से परिभाषित करने की आवश्यकता होती है आम नाम। references() फ़ंक्शन के लिए डेवलपर को उस तालिका को स्पष्ट रूप से परिभाषित करने की भी आवश्यकता होती है जिसे संदर्भ इंगित कर रहा है, जो इस उदाहरण में, उपयोगकर्ता तालिका है।

टेबल संरचना बनाई गई

     Column     |            Type             | Nullable |               Default
----------------+-----------------------------+----------+--------------------------------------
 id             | bigint                      | not null | nextval('invoices_id_seq'::regclass)
 user_id        | bigint                      |          |
 payment_method | character varying(255)      |          |
 paid_at        | timestamp without time zone |          |
 inserted_at    | timestamp without time zone | not null |
 updated_at     | timestamp without time zone | not null |

Indexes:
    "invoices_pkey" PRIMARY KEY, btree (id)
    "invoices_user_id_index" btree (user_id)
Foreign-key constraints:
    "invoices_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id)

दोनों प्रवास भी काफी समान हैं। जब बात references की आती है सुविधा को संभाला जाता है, कुछ अंतर हैं:

1. Ecto user_id . के लिए एक विदेशी-कुंजी बाधा बनाता है फ़ील्ड ("invoices_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id) ), जो उपयोगकर्ताओं और इनवॉइस तालिकाओं के बीच संदर्भात्मक अखंडता बनाए रखता है।

2. ActiveRecord स्वचालित रूप से user_id . के लिए एक अनुक्रमणिका बनाता है कॉलम। Ecto के लिए डेवलपर को इसके बारे में स्पष्ट होना चाहिए। यही कारण है कि माइग्रेशन में create index(:invoices, [:user_id]) है। बयान।

ActiveRecord:डेटा मैपिंग और एसोसिएशन

ActiveRecord अपने "कॉन्फ़िगरेशन पर सम्मेलन" आदर्श वाक्य के लिए जाना जाता है। यह डिफ़ॉल्ट रूप से मॉडल वर्ग के नाम का उपयोग करके डेटाबेस तालिका नामों का अनुमान लगाता है। User . नामक एक वर्ग , डिफ़ॉल्ट रूप से, users . का उपयोग करता है इसके स्रोत के रूप में तालिका। ActiveRecord तालिका के सभी स्तंभों को एक उदाहरण विशेषता के रूप में भी मैप करता है। डेवलपर्स को केवल तालिकाओं के बीच संघों को परिभाषित करने की आवश्यकता होती है। शामिल वर्गों और तालिकाओं का अनुमान लगाने के लिए इनका उपयोग ActiveRecord द्वारा भी किया जाता है।

एक नज़र डालें कि ActiveRecord का उपयोग करके उपयोगकर्ता और चालान तालिका कैसे मैप की जाती हैं:

उपयोगकर्ता

class User < ApplicationRecord
  has_many :invoices
end

चालान

class Invoice < ApplicationRecord
  belongs_to :user
end

एक्टो:डेटा मैपिंग और एसोसिएशन

दूसरी ओर, Ecto के लिए डेवलपर को डेटा स्रोत और उसके क्षेत्रों के बारे में स्पष्ट होना आवश्यक है। हालांकि Ecto में समान has_many है और belongs_to सुविधाएँ, इसके लिए डेवलपर्स को संबंधित तालिका और उस तालिका स्कीमा को संभालने के लिए उपयोग किए जाने वाले स्कीमा मॉड्यूल के बारे में स्पष्ट होना चाहिए।

इस प्रकार Ecto उपयोगकर्ताओं और इनवॉइस तालिकाओं को मैप करता है:

उपयोगकर्ता

defmodule Financex.Accounts.User do
  use Ecto.Schema
 
  schema "users" do
    field :full_name, :string
    field :email, :string
    has_many :invoices, Financex.Accounts.Invoice
    timestamps()
  end
end

चालान

defmodule Financex.Accounts.Invoice do
  use Ecto.Schema
 
  schema "invoices" do
    field :payment_method, :string
    field :paid_at, :utc_datetime
    belongs_to :user, Financex.Accounts.User
    timestamps()
  end
end

रैप अप

इस पोस्ट में, हमने बिना पलक झपकाए सेब और संतरे की तुलना की। हमने तुलना की कि कैसे ActiveRecord और Ecto डेटाबेस माइग्रेशन और मैपिंग को हैंडल करते हैं। स्पष्ट 'आई एम बैटमैन' बैटमैन बनाम निहित स्लिएंट ओरिजिनल बैटगर्ल की लड़ाई।

"कॉन्फ़िगरेशन पर सम्मेलन" के लिए धन्यवाद, ActiveRecord का उपयोग करने में आमतौर पर कम लेखन शामिल होता है। एक्टो विपरीत दिशा में जाता है, जिससे डेवलपर्स को अपने इरादों के बारे में अधिक स्पष्ट होने की आवश्यकता होती है। सामान्य रूप से "कम कोड" के बेहतर होने के अलावा, ActiveRecord में कुछ इष्टतम डिफ़ॉल्ट हैं जो डेवलपर को हर चीज पर निर्णय लेने और सभी अंतर्निहित कॉन्फ़िगरेशन को समझने से बचाते हैं। शुरुआती लोगों के लिए, ActiveRecord एक अधिक उपयुक्त समाधान है, क्योंकि यह डिफ़ॉल्ट रूप से "काफी अच्छे" निर्णय लेता है, जब तक आप इसके मानक का सख्ती से पालन करते हैं।

एक्टो का स्पष्ट पहलू कोड के एक टुकड़े के व्यवहार को पढ़ना और समझना आसान बनाता है, लेकिन इसके लिए डेवलपर को डेटाबेस गुणों और उपलब्ध सुविधाओं के बारे में अधिक समझने की भी आवश्यकता होती है। एक्टो पहली नज़र में बोझिल लग सकता है, यह इसका एक गुण है। ActiveRecord और Ecto दुनिया दोनों में मेरे व्यक्तिगत अनुभव के आधार पर, Ecto की खोजकर्ता "दृश्य के पीछे" प्रभावों और अनिश्चितता को दूर करती है जो ActiveRecord के साथ परियोजनाओं में आम है। एक डेवलपर कोड में जो पढ़ता है, वही एप्लिकेशन में होता है और कोई अंतर्निहित व्यवहार नहीं होता है।

कुछ हफ़्तों में एक दूसरे ब्लॉग में, दो भाग "ActiveRecord vs Ecto" श्रृंखला में, हम यह कवर करेंगे कि ActiveRecord और Ecto दोनों में क्वेरी और सत्यापन कैसे काम करते हैं।

हमें यह जानकर अच्छा लगेगा कि आपने इस लेख के बारे में क्या सोचा। हम हमेशा कवर करने के लिए नए विषयों की तलाश में रहते हैं, इसलिए यदि आपके पास कोई ऐसा विषय है जिसके बारे में आप अधिक जानना चाहते हैं, तो कृपया बेझिझक हमें @AppSignal पर बताएं!