Ruby on Rails에서 마이그레이션 사용

Question

다음 분석이 맞는지 확인하고 싶습니다.

RoR에 웹 응용 프로그램을 구축 중입니다. 데이터 구조가 내 postgres 데이터베이스에 대한 설계 (약 70 테이블,이 디자인을 할 때 레일스 방식으로 일을 반영하도록 개발 중에 변경 및 추가가 필요할 수 있습니다 .EG, 일부 사용자 및 역할 테이블을 디자인했습니다 -하지만 Restful 인증, 나는 그것들을 문질러서 RA가 요구하는 것으로 대체 할 것입니다.).

필자는 일련의 .sql 파일을 호출하여 테이블과 초기 데이터 (예 : 타운이 포스트 타운으로 미리 채워짐)와 테스트 데이터를 채우는 일련의 .sql 파일을 호출합니다 (예 : 더미 회사들과 함께 놀 수있는 데이터가 있음). 예를 들어

:

CREATE TABLE towns (
    id   integer PRIMARY KEY DEFAULT nextval ('towns_seq'), 
    county_id integer REFERENCES counties ON DELETE RESTRICT ON UPDATE CASCADE, 
    country_id integer REFERENCES countries ON DELETE RESTRICT ON UPDATE CASCADE NOT NULL, 
    name  text NOT NULL UNIQUE 
); 

제안 0 : 데이터는 더 이상 애플 리케이션보다 더 지속, 그래서 나는의 부족에도 불구하고, 내 RoR에 모델 참조 DB를 수준에서 시행 무결성뿐만 아니라 검증을 할 것을 확신합니다 DRYNESS.

제안 1 : 스크립트 및 sql 파일을 마이그레이션으로 대체하는 경우 현재 마이그레이션 코드 내에서 SQL DDL 파일에 설정된 외래 키 및 기타 제약 조건에 대해 내 Postgres 데이터베이스에 알려줄 수 없습니다.

명제 2 : 마이그레이션의 장점은 스키마 변경이 RoR 모델 코드와 함께 버전이 적용된다는 것입니다. 그러나 스크립트와 .sql 파일을 railsapp/db에 보관하면 쉽게 버전을 지정할 수 있습니다.

제안 3 : 마이그레이션 내가 원하는 기능이 부족하고, 내가 복제 할 수있는 혜택을 제공 감안할 때, 그 사용을 고려하는 나를 위해 작은 이유가있다. 그래서 나는 스크립트에서/skipmigrations해야/모델 시간을 생성합니다.

내 질문 : 법안 0이 수락되면 발의안 1,2,3이 참이거나 거짓입니까? 그 이유는 무엇입니까?

감사합니다.

Answer 1

적어도 두 가지 상황에서는 명제 1이 거짓입니다. foreign_key_migrations과 같은 플러그인을 사용할 수 있습니다. 다음 :

def self.up 
    create_table :users do |t| 
    t.column :department_id, :integer, :references => :departments 
    end 
end 

귀하의 DB에 적절한 외래 키 제약 조건을 생성합니다. 물론

, 당신은 두 번째 상황이 더 설득력이되는 경우에 당신이 당신의 DDL에하고 싶은 다른 일을 할 수도 있습니다 : 당신이 마이그레이션에 루비 DSL을 사용하도록 강요 아닙니다.대신 execute 방법을 시도해보십시오 그와

def self.up 
    execute 'YOUR SQL HERE' 
end 

, 당신은 당신이 언급하지 않은 후자 (가장 눈에 띄게 down 방법의 이점을 얻고, 마이그레이션에 SQL 스크립트의 내용을 유지할 수 있습니다 원래의 질문) 당신이 선호하는 저수준 컨트롤을 유지하십시오.

Answer 2

제안 1은 잘못된 것입니다. 마이그레이션에서 직접 SQL을 사용하는 경우에만 마이그레이션을 사용하여 참조 무결성을 명확하게 정의 할 수 있습니다. 자세한 내용은 this post을 참조하십시오.

제안 2 : 마이그레이션의 관심은 각 변경 사항을 추적하고 해당 변경 사항을 나중에 쉽게 롤백 할 수 있도록 점진적으로 데이터베이스 모델을 정의 할 수 있어야한다는 것입니다.

물건을 만들거나 수정하는 순서는 신중해야하지만 할 수는 있습니다.

레일은 응용 프로그램 중심 디자인에 더 적합합니다. Rails Way (tm)에서 데이터베이스는 응용 프로그램 활성 레코드 레이어를 통해서만 액세스되며 웹 서비스를 사용하여 외부에 데이터를 노출합니다.

Answer 3

1 : this plugin을 사용해 볼 수도 있습니다. 나는 직접 시도하지는 않았지만 마이그레이션을 통해 외래 키 제약 조건을 추가 할 수있는 것 같습니다.

2 : 마이그레이션의 실질적인 이점은 이 데이터베이스 기록에서 앞뒤로이 될 수 있다는 것입니다. 그것은 .sql 파일로는 쉽지 않습니다.

3 : 위에서 언급 한 플러그인이 당신에게 효과가 있는지 확인한 다음 결정하십시오 :) 어떤 경우에도 사용하지 않으면 큰 죄가 아닙니다!

Answer 4

Postgres를 사용하고 있으며 foreign_key_migrations 플러그인을 설치하지 않으려 고하므로 다음은 마이그레이션과 외래 키 제약 조건을 모두 사용하고자 할 때 수행하는 작업입니다.

"add_fk_constraint"라는 ActiveRecord :: SchemaStatements에 SchemaStatements 메서드를 추가합니다. 이것은 일부 중앙 집중화 된 파일에 포함될 수 있지만, 아래의 예제 마이그레이션 파일에서는 필자가 인라인으로 넣었습니다.

---

module ActiveRecord 
    module ConnectionAdapters # :nodoc: 
    module SchemaStatements 
     # Example call: 
     # add_fk_constraint 'orders','advertiser_id','advertisers','id' 
     # "If you want add/alter a 'orders' record, then its 'advertiser_id' had 
     # better point to an existing 'advertisers' record with corresponsding 'id'" 
     def add_fk_constraint(table_name, referencing_col, referenced_table, referenced_col) 
     fk_name = "#{table_name}_#{referencing_col}" 
     sql = <<-ENDSQL 
      ALTER TABLE #{table_name} 
      ADD CONSTRAINT #{fk_name} 
      FOREIGN KEY (#{referencing_col}) REFERENCES #{referenced_table} (#{referenced_col}) 
      ON UPDATE NO ACTION ON DELETE CASCADE; 
      CREATE INDEX fki_#{fk_name} ON #{table_name}(#{referencing_col}); 
     ENDSQL 
     execute sql 
     end 
    end 
    end 
end 

class AdvertisersOrders < ActiveRecord::Migration 
    def self.up 
    create_table :advertisers do |t| 
     t.column :name,    :string, :null => false 
     t.column :net_id,    :integer, :null => false 
     t.column :source_service_id, :integer, :null => false, :default => 1 
     t.column :source_id,   :integer, :null => false 
    end 

    create_table :orders do |t| 
     t.column :name,    :string, :null => false 
     t.column :advertiser_id,  :integer, :null => false 
     t.column :source_id,   :integer, :null => false 
    end 
    add_fk_constraint 'orders','advertiser_id','advertisers','id' 
    end 

    def self.down 
    drop_table :orders 
    drop_table :advertisers 
    end 
end 

---

나는이 사람을 도움 기대하고있다. SQL "COPY"호출로 많은 외부 제공 데이터를로드해야하기 때문에 나에게 매우 유용했지만 마이그레이션 시스템이 매우 편리하다는 것을 알게되었습니다.