2
웹 응용 프로그램을 빌드 할 때 마이그레이션 파일의 긴 목록이 자주 존재합니까? 내가 잊어 버린 또는 '이미'마이 그 레이션 된 데이터베이스 테이블에 여분의 열을 추가 생각을 계속하기 때문에 나는 마이 그 레이션 파일의 긴 목록을 추가하는 것 같습니다.Ruby on Rails : 마이그레이션 파일의 긴 목록이 일반적입니까?
A
답변
0
IMO, 마이그레이션을 올바르게 수행하려면 마이그레이션 목록이 길어야합니다. 마이그레이션을 통해 수행해야하는 모든 작은 변화를 고려하십시오. 앞에서 말한 것처럼 적절한 방법은 테이블을 변경해야 할 때 새로운 마이그레이션을 추가하는 것입니다.
제가 언급했듯이 마이그레이션이 점점 더 많아지는 것은 올바른 일이라는 것을 의미합니다. (대부분의 경우 기존 테이블에 대한 변경이 필요할 때 간단히 테이블을 삭제하고 다시 만들 수 없습니다.)
하지만 언제든지 rake db:migrate을 실행하는 것이 좋습니다. 격리 된 db)를 사용하여 마이그레이션이 그룹으로 작동하는지 확인하십시오.
3
마이그레이션 파일 목록이 길면 정상입니다. 그것은 레일의 가장 좋은 특징 중 하나입니다. 그것들을 당신이 서로의 위에 쌓는 층 (양파처럼)이라고 생각하십시오. 새로운 열이나 테이블을 추가 한 다음 더 이상 원하지 않는다고 결정하면 최신 변경 사항을 롤백 (떼어 낼 수 있습니다) 할 수 있습니다. 마이그레이션 파일을 가지고있는 한 쉽게 이동할 수 있습니다 (많이 움직이는 것은 권장하지 않지만 요점은 알 수 있습니다). 기억해두기 롤백을하지 않으면 이동 파일을 긁어 모으지 않습니다. 마이그레이션 파일을 롤백하고 삭제할 때 올바른 계층 (롤백 지점)에 있는지 확인하십시오.
왜? 예를 들어 누군가가 앱을 복제하고 마이그레이션 파일을 실행할 때 처음부터 끝까지 모든 마이그레이션 파일을 검토하기 때문입니다. 중간에있는 것이 엉망이거나 삭제되면 모든 단계를 거치므로 데이터베이스를 만들 수 없습니다. 희망이 도움이됩니다.
0
좋지 않은 습관이 있지만 rake db:migrate VERSION=0을 사용하여 마이 그 레이션 한 다음 (예 : 사용자가있는) 해당 마이 그 레이션을 변경하고 마지막으로 rake db:migrate을 사용하여 데이터베이스를 마이 그 레이션합니다. 그런 식으로 나는 혼란이 적고 어떤 마이그레이션이 어떤 모델을하는지 정확히 알 수 있습니다. 그것은 더 깨끗한지만,이 기술은 webapp의 시작 부분에서만 사용할 수있을 것 같아요. 희망이 도움이됩니다. 처음부터 모든 마이그레이션을 실행하지 않는, 부하 : 스키마 :
0
또 하나의 포인트가 레일 문서
다른 시스템에서 응용 프로그램 데이터베이스를 작성해야하는 경우
에서, 주목해야한다, 당신은 DB를 사용한다. 후자는 결함이 있고 유지할 수없는 접근 방식입니다. 더 많은 마이그레이션을 수행 할수록 실행 속도가 느려지고 문제가 발생할 확률이 높아집니다.이 파일 (schema.rb)을 버전 제어 시스템으로 확인하는 것이 좋습니다.