ActiveRecord 및 Exto - 첫 번째 섹션

데이터는 대부분의 소프트웨어 응용 프로그램의 핵심 부분이다.데이터베이스에서 데이터를 비추고 조회하는 것은 개발자의 생명 주기 중의 일상적인 임무이다.따라서 절차를 이해하고 임무를 간소화할 수 있는 추상이 중요하다.
이 기사에서는 ActiveRecord(Ruby)와 Ecto(Elixir) 사이의 비교를 볼 수 있습니다.우리는 이 두 가지 도구가 개발자로 하여금 어떻게 데이터베이스 모델을 이전하고 비추게 하는지 보게 할 것이다.
그래서 우리는 사과와 오렌지를 비교할 것이다.(오리지널) 배트맨 소녀는 한마디도 할 필요가 없었다. 배트맨에게 "나는 배트맨이다"라고 분명히 말했다.명확한 의도가 아니라 설정보다 은밀한 약속.1라운드.전투!

ActiveRecord

발표된 지 10여 년이 지난 후,Active Record-Ruby on Rails 프로젝트에 기본적으로 첨부된 유명 제품ORM에 대해 들은 적이 있을 것이다.

ActiveRecord is the M in MVC - the model - which is the layer of the system responsible for representing business data and logic. ActiveRecord facilitates the creation and use of business objects whose data requires persistent storage in a database. It is an implementation of the ActiveRecord pattern which is itself, a description of an Object Relational Mapping system.

ActiveRecord는 주로 Rails에 사용되는 것으로 알려져 있지만, 다른 프로젝트에 끼워 넣을 수 있는 독립된 도구이기도 하다.

외배층

Active Record에 비해 Exto는 매우 새로운 도구이다.그것은 불로장생의 약으로 작성된 것으로 기본적으로 봉황성 프로젝트에 포함된다.
Active Record와 달리 Exto는 ORM이 아닌 라이브러리로, Elixir를 사용하여 질의를 작성하고 데이터베이스와 상호 작용할 수 있습니다.

Ecto is a domain specific language for writing queries and interacting with databases in Elixir.

설계상 Ecto는 서로 다른 Elixir 프로젝트에 사용되며 프레임에 연결되지 않습니다.

너는 사과와 오렌지를 비교하고 있지 않니?

그래, 우리는!ActiveRecord와 Exto는 의미는 다르지만 ActiveRecord와 Exto는 데이터베이스 마이그레이션, 데이터베이스 매핑, 조회와 검증 등 흔한 기능을 지원한다.우리는 이 두 가지 도구를 사용하여 같은 결과를 얻을 수 있다.루비 배경에서 온 불로장생약에 관심이 있는 사람들에게 우리는 이것이 흥미로운 비교가 될 것이라고 생각한다.

영수증 시스템

이 글의 나머지 부분에서는 하나의 가설적인 영수증 시스템을 사용하여 시범을 보일 것이다.슈퍼히어로에게 양복을 파는 상점이 있다고 상상해 보자.간단하게 보기 위해서 영수증 시스템은 두 개의 표만 있는데 그것이 바로 사용자와 영수증이다.
다음은 이러한 테이블의 구조와 해당 필드 및 유형입니다.
사용자
마당
타입
전명
꿰미
전자 우편
꿰미
(ActiveRecord)에서 만들기/삽입(Exto)
약속 시간
주소 업데이트
약속 시간
인보이스
마당
타입
사용자 id
정수
지불 방식
꿰미
보수를 지불하다
약속 시간
(ActiveRecord)에서 만들기/삽입(Exto)
약속 시간
주소 업데이트
약속 시간
사용자 테이블에는 도구에 따라 네 개의 필드가 있습니다. 전체 이름, 전자 우편, 주소 업데이트, 네 번째 필드입니다.ActiveRecord는created at 필드를 만들고 Exto는inserted at 필드를 만들어서 데이터베이스에 처음 삽입되었을 때의 시간 스탬프를 표시합니다.
두 번째 표의 이름은 invoices입니다.이것은 다섯 개의 필드가 있습니다: user id,payment method,payment at,updated at,users 테이블과 유사한created at 또는 inserted at. 구체적인 것은 사용하는 도구에 달려 있습니다.
사용자와 청구서 테이블은 다음과 연관되어 있습니다.

한 사용자가 많은 영수증을 가지고 있다

청구서는 사용자에 해당

이사하다

이전은 개발자들이 교체 과정을 사용하여 시간에 따라 그들의 데이터베이스 모델을 쉽게 진화시킬 수 있게 한다.Active Record와 Exto는 개발자가 직접 처리SQL가 아닌 고급 언어(루비와 Elixir)로 데이터베이스 모델을 이전할 수 있도록 한다.
Active Record와 Exto에서 마이그레이션이 어떻게 작동하는지 살펴보고 사용자와 영수증을 만들 수 있습니다.

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를 사용하면 Active Record를 트리거하여 이 두 필드를 만들 수 있습니다.
생성된 테이블 구조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

EXTO 마이그레이션은 함수create()와 table()를 결합하여 사용자 테이블을 만듭니다.EXTO 마이그레이션 파일은 ActiveRecord와 동일합니다.Active Record에서는 타임 스탬프 필드(created_at와 updated_at가 t.timestamps로 작성되고 Exto에서는 타임 스탬프 필드(inserted_at와 updated_at가 timestamps() 함수로 작성됩니다.
이 두 가지 도구는 색인을 만드는 방식에 있어서 약간 다르다.ActiveRecord에서 색인은 작성된 필드의 옵션으로 정의됩니다.EXTO는 함수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:청구서 양식 작성

옮기다

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 방법은 인용을 저장하기 위해 invoices표에 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입니다. t.references 방법을 사용하면 ActiveRecord에서 자동으로 이 인덱스를 추가합니다.

청구서 양식 작성

옮기다

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

Exto는 references() 함수를 사용하여 데이터베이스 참조를 만들 수도 있습니다.Ecto는 열 이름을 추정하는 Active Record와 달리 개발자에게 열 이름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 기능의 처리 방식에 대해 말하자면 몇 가지 다른 점이 있다.

Ecto는 user_id 필드"invoices_user_id_fkey" FOREIGN KEY (user_id) REFERENCES users(id)에 키 제약을 만들고 이 필드는 사용자와 영수증 표 간의 인용 완전성을 유지한다.

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와 Exto가 데이터베이스 마이그레이션과 매핑을 처리하는 방식을 비교했습니다.함축적이고 침묵한 원시 배트맨과 노골적인'나는 배트맨이다'배트맨의 대결이었다.
"약속이 설정보다 우선"덕분에 Active Record를 사용하려면 보통 더 적은 쓰기가 필요합니다.Ecto의 방향은 정반대이다. 개발자에게 자신의 의도를 더욱 명확하게 표현하도록 요구한다.'더 적은 코드' 가 일반적으로 더 좋은 것 이외에Active Record는 개발자가 모든 일에 대해 결정을 내릴 필요도, 모든 하위 설정을 이해할 필요도 없는 가장 좋은 기본 설정을 가지고 있다.초보자에게ActiveRecord는 더욱 적합한 해결 방안이다. 왜냐하면 엄격하게 그 기준을 따르기만 하면 기본적으로 '충분하다' 는 결정을 내릴 수 있기 때문이다.
Ecto의 현식 특성은 코드의 행동을 더욱 쉽게 읽고 이해할 수 있도록 하지만, 개발자에게 데이터베이스 속성과 사용 가능한 기능에 대한 더 많은 정보를 요구한다.언뜻 보기에 Exto의 장점 중 하나는 그것을 무거워 보일 수도 있다.Active Record와 Exto world에서의 제 개인 경험에 따르면 Exto의 명확성은 Active Record를 사용하는 프로젝트에서 흔히 볼 수 있는'비하인드'영향과 불확실성을 없앴습니다.개발자가 코드에서 읽은 내용은 응용 프로그램에서 발생한 내용으로 은밀한 행위가 없다.
몇 주 뒤 두 번째 블로그에서는'Active Record vs Exto'시리즈의 두 부분에서 Active Record와 Exto에서 어떻게 조회하고 검증하는지 소개할 예정이다.
우리는 네가 이 문장에 대한 견해를 매우 알고 싶다.우리는 줄곧 새로운 화제를 찾고 있기 때문에 만약 당신이 주제가 있다면 더 많은 것을 알고 싶으면 주저하지 말고 댓글을 남겨주세요!
이 글은 객원작가Elvio Vicosa가 썼다.엘비오는 이 책의 저자Phoenix for Rails Developers다.