기존 데이터베이스를 사용 하 여 Code First 마이그레이션Code First Migrations with an existing database

참고

Ef 4.3 이상-이 페이지에서 설명 하는 기능, api 등은 Entity Framework 4.1에서 도입 되었습니다.EF4.3 Onwards Only - The features, APIs, etc. discussed in this page were introduced in Entity Framework 4.1. 이전 버전을 사용하는 경우 이 정보의 일부 또는 전체가 적용되지 않습니다.If you are using an earlier version, some or all of the information does not apply.

이 문서에서는 Entity Framework에 의해 생성 되지 않은 기존 데이터베이스와 Code First 마이그레이션를 사용 하는 방법을 설명 합니다.This article covers using Code First Migrations with an existing database, one that wasn’t created by Entity Framework.

참고

이 문서에서는 기본 시나리오에서 Code First 마이그레이션를 사용 하는 방법을 알고 있다고 가정 합니다.This article assumes you know how to use Code First Migrations in basic scenarios. 그렇지 않으면 계속 하기 전에 Code First 마이그레이션 읽어야 합니다.If you don’t, then you’ll need to read Code First Migrations before continuing.

스크린 캐스트Screencasts

이 문서를 읽는 것 보다 동영상 가이드을 시청 하는 경우 다음 두 비디오는이 문서와 동일한 콘텐츠를 포함 합니다.If you'd rather watch a screencast than read this article, the following two videos cover the same content as this article.

비디오 1: "마이그레이션-내부"Video One: "Migrations - Under the Hood"

이 동영상 가이드 는 마이그레이션이 모델 변경 내용을 검색 하는 모델에 대 한 정보를 추적 하 고 사용 하는 방법을 설명 합니다.This screencast covers how migrations tracks and uses information about the model to detect model changes.

비디오 2: "마이그레이션-기존 데이터베이스"Video Two: "Migrations - Existing Databases"

이전 비디오에서 개념을 기반으로 구축 된 이 동영상 가이드 는 기존 데이터베이스에서 마이그레이션을 사용 하도록 설정 하 고 사용 하는 방법을 다룹니다.Building on the concepts from the previous video, this screencast covers how to enable and use migrations with an existing database.

1 단계: 모델 만들기Step 1: Create a model

첫 번째 단계는 기존 데이터베이스를 대상으로 하는 Code First 모델을 만드는 것입니다.Your first step will be to create a Code First model that targets your existing database. 기존 데이터베이스에 Code First 항목은이 작업을 수행 하는 방법에 대 한 자세한 지침을 제공 합니다.The Code First to an Existing Database topic provides detailed guidance on how to do this.

참고

데이터베이스 스키마를 변경 해야 하는 모델을 변경 하기 전에이 항목의 나머지 단계를 수행 하는 것이 중요 합니다.It is important to follow the rest of the steps in this topic before making any changes to your model that would require changes to the database schema. 다음 단계를 수행 하려면 모델을 데이터베이스 스키마와 동기화 해야 합니다.The following steps require the model to be in-sync with the database schema.

2 단계: 마이그레이션 사용Step 2: Enable Migrations

다음 단계는 마이그레이션을 사용 하도록 설정 하는 것입니다.The next step is to enable migrations. 패키지 관리자 콘솔에서 마이그레이션 사용 명령을 실행 하 여이 작업을 수행할 수 있습니다.You can do this by running the Enable-Migrations command in Package Manager Console.

이 명령은 솔루션에서 마이그레이션 이라는 폴더를 만들고 구성 이라는 단일 클래스를 포함 합니다.This command will create a folder in your solution called Migrations, and put a single class inside it called Configuration. 구성 클래스에서는 응용 프로그램에 대 한 마이그레이션을 구성할 수 있으며,이에 대 한 자세한 내용은 Code First 마이그레이션 항목에서 확인할 수 있습니다.The Configuration class is where you configure migrations for your application, you can find out more about it in the Code First Migrations topic.

3 단계: 초기 마이그레이션 추가Step 3: Add an initial migration

마이그레이션을 만들고 로컬 데이터베이스에 적용 한 후에는 이러한 변경 내용을 다른 데이터베이스에 적용할 수도 있습니다.Once migrations have been created and applied to the local database you may also want to apply these changes to other databases. 예를 들어 로컬 데이터베이스는 테스트 데이터베이스이 고 궁극적으로 프로덕션 데이터베이스 및/또는 다른 개발자 테스트 데이터베이스에 변경 내용을 적용 하려는 경우가 있습니다.For example, your local database may be a test database and you may ultimately want to also apply the changes to a production database and/or other developers test databases. 이 단계에서는 두 가지 옵션을 사용할 수 있으며, 선택 해야 하는 옵션은 다른 데이터베이스의 스키마가 비어 있거나 현재 로컬 데이터베이스의 스키마와 일치 하는지 여부에 따라 달라 집니다.There are two options for this step and the one you should pick depends whether or not the schema of any other databases is empty or currently matches the schema of the local database.

  • 옵션 1: 기존 스키마를 시작 지점으로 사용 합니다.Option One: Use existing schema as starting point. 나중에 마이그레이션에 적용 되는 다른 데이터베이스에 현재 로컬 데이터베이스와 동일한 스키마가 있는 경우이 방법을 사용 해야 합니다.You should use this approach when other databases that migrations will be applied to in the future will have the same schema as your local database currently has. 예를 들어 로컬 테스트 데이터베이스가 현재 프로덕션 데이터베이스의 v1과 일치 하 고 나중에 이러한 마이그레이션을 적용 하 여 프로덕션 데이터베이스를 v 2로 업데이트 하는 경우이를 사용할 수 있습니다.For example, you might use this if your local test database currently matches v1 of your production database and you will later apply these migrations to update your production database to v2.
  • 옵션 2: 빈 데이터베이스를 시작 지점으로 사용 합니다.Option Two: Use empty database as starting point. 나중에 마이그레이션이 적용 되는 다른 데이터베이스가 비어 있거나 아직 존재 하지 않는 경우이 방법을 사용 해야 합니다.You should use this approach when other databases that migrations will be applied to in the future are empty (or do not exist yet). 예를 들어, 테스트 데이터베이스를 사용 하 여 응용 프로그램 개발을 시작 했지만 마이그레이션을 사용 하지 않고 나중에 프로덕션 데이터베이스를 처음부터 만들려는 경우이를 사용할 수 있습니다.For example, you might use this if you started developing your application using a test database but without using migrations and you will later want to create a production database from scratch.

옵션 1: 기존 스키마를 시작 지점으로 사용 합니다.Option One: Use existing schema as a starting point

Code First 마이그레이션은 최신 마이그레이션에 저장 된 모델의 스냅숏을 사용 하 여 모델에 대 한 변경 내용을 검색 합니다 .이에 대 한 자세한 내용은 팀 환경 Code First 마이그레이션에서 확인할 수 있습니다.Code First Migrations uses a snapshot of the model stored in the most recent migration to detect changes to the model (you can find detailed information about this in Code First Migrations in Team Environments). 데이터베이스에 현재 모델의 스키마가 이미 있다고 가정 하기 때문에 현재 모델을 스냅숏으로 포함 하는 빈 (op 없음) 마이그레이션을 생성 합니다.Since we are going to assume that databases already have the schema of the current model, we will generate an empty (no-op) migration that has the current model as a snapshot.

  1. 패키지 관리자 콘솔에서 추가-마이그레이션 InitialCreate – IgnoreChanges 명령을 실행 합니다.Run the Add-Migration InitialCreate –IgnoreChanges command in Package Manager Console. 그러면 현재 모델을 스냅숏으로 빈 마이그레이션이 생성 됩니다.This creates an empty migration with the current model as a snapshot.
  2. 패키지 관리자 콘솔에서 업데이트 데이터베이스 명령을 실행 합니다.Run the Update-Database command in Package Manager Console. 이렇게 하면 데이터베이스에 InitialCreate migration이 적용 됩니다.This will apply the InitialCreate migration to the database. 실제 마이그레이션에는 변경 내용이 포함 되어 있지 않으므로 _ _ 이 마이그레이션이 이미 적용 되었음을 나타내는 행을 MigrationsHistory 테이블에 추가 하면 됩니다.Since the actual migration doesn’t contain any changes, it will simply add a row to the __MigrationsHistory table indicating that this migration has already been applied.

옵션 2: 빈 데이터베이스를 시작 지점으로 사용Option Two: Use empty database as a starting point

이 시나리오에서는 로컬 데이터베이스에 이미 있는 테이블을 포함 하 여 전체 데이터베이스를 처음부터 새로 만들 수 있는 마이그레이션이 필요 합니다.In this scenario we need Migrations to be able to create the entire database from scratch – including the tables that are already present in our local database. 기존 스키마를 만드는 논리를 포함 하는 InitialCreate migration을 생성할 예정입니다.We’re going to generate an InitialCreate migration that includes logic to create the existing schema. 그런 다음이 마이그레이션과 이미 적용 된 것 처럼 기존 데이터베이스를 만듭니다.We’ll then make our existing database look like this migration has already been applied.

  1. 패키지 관리자 콘솔에서 추가 마이그레이션 InitialCreate 명령을 실행 합니다.Run the Add-Migration InitialCreate command in Package Manager Console. 이렇게 하면 기존 스키마를 만드는 마이그레이션이 생성 됩니다.This creates a migration to create the existing schema.
  2. 새로 만든 마이그레이션의 Up 메서드에서 모든 코드를 주석으로 처리 합니다.Comment out all code in the Up method of the newly created migration. 이렇게 하면 이미 존재 하는 모든 테이블 등을 다시 만들려고 하지 않고 로컬 데이터베이스에 대 한 마이그레이션을 ' 적용 ' 할 수 있습니다.This will allow us to ‘apply’ the migration to the local database without trying to recreate all the tables etc. that already exist.
  3. 패키지 관리자 콘솔에서 업데이트 데이터베이스 명령을 실행 합니다.Run the Update-Database command in Package Manager Console. 이렇게 하면 데이터베이스에 InitialCreate migration이 적용 됩니다.This will apply the InitialCreate migration to the database. 실제 마이그레이션에는 변경 내용이 포함 되어 있지 않기 때문에 (일시적으로 주석 처리 되기 때문에) _ _ 이 마이그레이션이 이미 적용 되었음을 나타내는 행이 MigrationsHistory 테이블에 추가 됩니다.Since the actual migration doesn’t contain any changes (because we temporarily commented them out), it will simply add a row to the __MigrationsHistory table indicating that this migration has already been applied.
  4. Up 메서드에서 코드의 주석을 해제 합니다.Un-comment the code in the Up method. 즉,이 마이그레이션이 이후 데이터베이스에 적용 되는 경우 로컬 데이터베이스에 이미 있던 스키마는 마이그레이션에 의해 생성 됩니다.This means that when this migration is applied to future databases, the schema that already existed in the local database will be created by migrations.

알아두어야 할 사항Things to be aware of

기존 데이터베이스에 대해 마이그레이션을 사용할 때 알아야 할 몇 가지 사항이 있습니다.There are a few things you need to be aware of when using Migrations against an existing database.

기본/계산 된 이름이 기존 스키마와 일치 하지 않을 수 있습니다.Default/calculated names may not match existing schema

마이그레이션은 마이그레이션을 스 캐 폴드 때 열과 테이블의 이름을 명시적으로 지정 합니다.Migrations explicitly specifies names for columns and tables when it scaffolds a migrations. 그러나 마이그레이션은 마이그레이션을 적용할 때의 기본 이름을 계산 하는 다른 데이터베이스 개체가 있습니다.However, there are other database objects that Migrations calculates a default name for when applying the migrations. 여기에는 인덱스와 foreign key 제약 조건이 포함 됩니다.This includes indexes and foreign key constraints. 기존 스키마를 대상으로 지정 하는 경우 이러한 계산 된 이름이 데이터베이스에 실제로 존재 하는 이름과 일치 하지 않을 수 있습니다.When targeting an existing schema, these calculated names may not match what actually exists in your database.

다음은이에 대해 알고 있어야 하는 경우의 몇 가지 예입니다.Here are some examples of when you need to be aware of this:

' 옵션 1: 기존 스키마를 시작 지점으로 사용 '을 사용 하는 경우 3 단계:If you used ‘Option One: Use existing schema as a starting point’ from Step 3:

  • 나중에 모델을 변경할 때 이름이 다른 데이터베이스 개체 중 하나를 변경 하거나 삭제 해야 하는 경우에는 스 캐 폴드 마이그레이션을 수정 하 여 올바른 이름을 지정 해야 합니다.If future changes in your model require changing or dropping one of the database objects that is named differently, you will need to modify the scaffolded migration to specify the correct name. 마이그레이션 Api에는이 작업을 수행할 수 있는 선택적 이름 매개 변수가 있습니다.The Migrations APIs have an optional Name parameter that allows you to do this. 예를 들어 기존 스키마에 인덱스 이름이 IndexFk BlogId 인 BlogId 외래 키 열이 있는 Post 테이블이 있을 수 있습니다 _ .For example, your existing schema may have a Post table with a BlogId foreign key column that has an index named IndexFk_BlogId. 그러나 기본적으로 마이그레이션은이 인덱스의 이름을 IX BlogId로 지정 _ 합니다.However, by default Migrations would expect this index to be named IX_BlogId. 이 인덱스를 삭제 하는 모델을 변경 하는 경우에는 스 캐 폴드 DropIndex 호출을 수정 하 여 IndexFk BlogId name을 지정 해야 합니다 _ .If you make a change to your model that results in dropping this index, you will need to modify the scaffolded DropIndex call to specify the IndexFk_BlogId name.

' 옵션 2: 빈 데이터베이스를 시작 지점으로 사용 '을 사용 하는 경우 3 단계:If you used ‘Option Two: Use empty database as a starting point’ from Step 3:

  • 마이그레이션이 잘못 된 이름을 사용 하 여 인덱스와 foreign key 제약 조건을 삭제 하려고 하기 때문에 로컬 데이터베이스에 대해 초기 마이그레이션 (즉, 빈 데이터베이스로 되돌리기)의 다운 메서드를 실행 하려고 하면 실패할 수 있습니다.Trying to run the Down method of the initial migration (that is, reverting to an empty database) against your local database may fail because Migrations will try to drop indexes and foreign key constraints using the incorrect names. 이는 초기 마이그레이션의 Up 메서드를 사용 하 여 다른 데이터베이스를 처음부터 만들기 때문에 로컬 데이터베이스에만 영향을 줍니다.This will only affect your local database since other databases will be created from scratch using the Up method of the initial migration. 기존 로컬 데이터베이스를 빈 상태로 다운 그레이드 하려면 데이터베이스를 삭제 하거나 모든 테이블을 삭제 하 여이 작업을 수동으로 수행 하는 것이 가장 쉽습니다.If you want to downgrade your existing local database to an empty state it is easiest to do this manually, either by dropping the database or dropping all the tables. 이 초기 다운 그레이드 후에는 모든 데이터베이스 개체가 기본 이름으로 다시 생성 되므로이 문제는 다시 표시 되지 않습니다.After this initial downgrade all database objects will be recreated with the default names, so this issue will not present itself again.
  • 나중에 모델을 변경할 때 이름이 다른 데이터베이스 개체 중 하나를 변경 하거나 삭제 해야 하는 경우에는 이름이 기본값과 일치 하지 않기 때문에 기존 로컬 데이터베이스에 대해이 작업을 수행할 수 없습니다.If future changes in your model require changing or dropping one of the database objects that is named differently, this will not work against your existing local database – since the names won’t match the defaults. 그러나 마이그레이션에 의해 선택 된 기본 이름을 사용 하기 때문에 ' 처음부터 새로 만든 ' 데이터베이스에 대해 작동 합니다.However, it will work against databases that were created ‘from scratch’ since they will have used the default names chosen by Migrations. 이러한 변경 내용을 로컬 기존 데이터베이스에서 수동으로 변경 하거나, 마이그레이션을 통해 데이터베이스를 처음부터 다시 만드는 것을 고려할 수 있습니다.You could either make these changes manually on your local existing database, or consider having Migrations recreate your database from scratch – as it will on other machines.
  • 초기 마이그레이션을 사용 하 여 만든 데이터베이스는 인덱스 및 foreign key 제약 조건에 대해 계산 된 기본 이름을 사용 하기 때문에 로컬 데이터베이스와 약간 다를 수 있습니다.Databases created using the Up method of your initial migration may differ slightly from the local database since the calculated default names for indexes and foreign key constraints will be used. 마이그레이션은 기본적으로 외래 키 열에 인덱스를 만들기 때문에 추가 인덱스가 생성 될 수도 있습니다. 원래 로컬 데이터베이스에 있는 경우가 아닐 수 있습니다.You may also end up with extra indexes as Migrations will create indexes on foreign key columns by default – this may not have been the case in your original local database.

모든 데이터베이스 개체가 모델에 표시 되는 것은 아닙니다.Not all database objects are represented in the model

모델에 포함 되지 않은 데이터베이스 개체는 마이그레이션에 의해 처리 되지 않습니다.Database objects that are not part of your model will not be handled by Migrations. 여기에는 뷰, 저장 프로시저, 사용 권한, 모델에 포함 되지 않은 테이블, 추가 인덱스 등이 포함 될 수 있습니다.This can include views, stored procedures, permissions, tables that are not part of your model, additional indexes, etc.

다음은이에 대해 알고 있어야 하는 경우의 몇 가지 예입니다.Here are some examples of when you need to be aware of this:

  • ' 3 단계 '에서 선택한 옵션에 관계 없이 나중에 모델을 변경할 때 이러한 추가 개체를 변경 하거나 삭제 해야 하는 경우 마이그레이션은 이러한 변경을 수행 하는 것을 알 수 없습니다.Regardless of the option you chose in ‘Step 3’, if future changes in your model require changing or dropping these additional objects Migrations will not know to make these changes. 예를 들어 추가 인덱스가 있는 열을 삭제 하는 경우 마이그레이션은 인덱스를 삭제 하는 것을 알 수 없습니다.For example, if you drop a column that has an additional index on it, Migrations will not know to drop the index. 스 캐 폴드 마이그레이션에 수동으로 추가 해야 합니다.You will need to manually add this to the scaffolded Migration.
  • ' 옵션 2: 빈 데이터베이스를 시작 지점으로 사용 '을 사용한 경우 초기 마이그레이션의 Up 메서드에서 이러한 추가 개체를 만들지 않습니다.If you used ‘Option Two: Use empty database as a starting point’, these additional objects will not be created by the Up method of your initial migration. 원하는 경우 이러한 추가 개체를 처리 하도록 위쪽 및 아래쪽 메서드를 수정할 수 있습니다.You can modify the Up and Down methods to take care of these additional objects if you wish. 뷰 등의 마이그레이션 API에서 기본적으로 지원 되지 않는 개체의 경우 sql 메서드를 사용 하 여 원시 sql을 실행 하 고 해당 개체를 만들거나 삭제할 수 있습니다.For objects that are not natively supported in the Migrations API – such as views – you can use the Sql method to run raw SQL to create/drop them.