데이터베이스 구조 변경을위한 버전 관리 시스템이 있습니까?

데이터베이스 구조 변경을위한 버전 관리 시스템이 있습니까?

---

나는 종종 다음과 같은 문제가 발생합니다.

데이터베이스에서 새 테이블이나 열이 필요한 프로젝트의 일부 변경 작업을 수행합니다. 데이터베이스를 수정하고 작업을 계속합니다. 일반적으로 변경 사항을 기록하여 라이브 시스템에서 복제 할 수 있도록합니다. 그러나, 나는 내가 바꿨 던 것을 항상 기억하지 않으며 항상 그것을 적어 놓는 것을 기억하지 않습니다.

그래서 나는 라이브 시스템을 강요하고 없다는 명백한 큰 오류를 얻습니다 NewColumnX.

이것이이 상황에 가장 적합한 방법이 아니라는 사실에 관계없이 데이터베이스 용 버전 제어 시스템이 있습니까? 특정 데이터베이스 기술에 관심이 없습니다. 하나만 존재하는지 알고 싶습니다. MS SQL Server와 함께 작동하면 훌륭합니다.

---

Ruby on Rails 에는 데이터베이스를 변경하는 빠른 스크립트 인 마이그레이션 개념 이 있습니다.

DB 파일을 늘리는 규칙 (예 : 열 추가)과 버전을 다운 그레이드하는 규칙 (예 : 열 제거)이있는 마이그레이션 파일을 생성합니다. 각 마이그레이션에는 번호가 매겨지고 테이블은 현재 DB 버전을 추적합니다.

마이그레이션 하려면 버전을 확인하고 필요한 스크립트를 적용하는 "db : migrate"라는 명령을 실행하십시오. 비슷한 방식으로 마이그레이션 할 수 있습니다.

마이그레이션 스크립트 자체는 버전 제어 시스템에 유지됩니다. 데이터베이스를 변경할 때마다 새 스크립트를 체크인하면 모든 개발자가 로컬 DB를 최신 버전으로 가져 오기 위해이를 적용 할 수 있습니다.

---

데이터베이스를 만들기 위해 소스 파일을 사용한다는 점에서 약간 구식입니다. 실제로는 두 개의 파일 (project-database.sql 및 project-updates.sql)이 있으며, 첫 번째는 스키마 및 지속성 데이터를위한 것이고, 두 번째는 수정을위한 것입니다. 물론 둘 다 소스 제어하에 있습니다.

데이터베이스가 변경되면 먼저 project-database.sql에서 기본 스키마를 업데이트 한 다음 관련 정보를 project-updates.sql에 복사합니다 (예 : ALTER TABLE 문). 그런 다음 개발 데이터베이스에 업데이트를 적용하고, 테스트가 끝날 때까지 반복 할 수 있습니다. 그런 다음 파일을 체크인하고 다시 테스트 한 후 프로덕션에 적용하십시오.

또한 일반적으로 db-Config에 테이블이 있습니다.

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

그런 다음 업데이트 섹션에 다음을 추가합니다.

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

db_version는 데이터베이스가 다시 때 변화 도착하고는 db_revision나에게 DB를 기준 떨어져 얼마나 멀리 표시를 제공합니다.

업데이트를 별도의 파일로 유지할 수는 있었지만 모두 함께 으깨고 잘라 내기 및 붙여 넣기를 사용하여 관련 섹션을 추출하기로했습니다. 좀 더 정리가 필요합니다. 즉 $ Revision 1.1 $에서 ':'을 제거하여 고정시킵니다.

---

MyBatis (이전의 iBatis)에는 명령 줄에서 사용할 수 있는 스키마 마이그레이션 도구가 있습니다. 모든 프로젝트에서 사용할 수 있지만 Java로 작성되었습니다.

데이터베이스 변경 관리를 효과적으로 수행하려면 몇 가지 주요 목표를 식별해야합니다. 따라서 MyBatis Schema Migration System (또는 MyBatis Migrations)은 다음을 추구합니다.

• 새 데이터베이스 또는 기존 데이터베이스와 작업
• 소스 제어 시스템 활용 (예 : Subversion)
• 동시 개발자 또는 팀이 독립적으로 작업 할 수 있도록 지원
• 갈등을 눈에 잘 띄고 쉽게 관리 가능
• 정방향 및 역방향 마이그레이션 허용 (각각 진화, 전개)
• 데이터베이스의 현재 상태를 쉽게 액세스하고 이해할 수 있도록하십시오
• 액세스 권한이나 관료주의에도 불구하고 마이그레이션 가능
• 모든 방법론으로 작업
• 우수하고 일관된 관행을 장려

---

Redgate에는 SQL Source Control 이라는 제품이 있습니다. TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce 및 Git과 통합됩니다.

---

나는 SQL 델타를 강력히 추천한다 . 내 기능을 코딩하고 소스 제어 도구 (Mercurial :)로 스크립트를 확인하면 diff 스크립트를 생성하는 데 사용합니다.

SQL 서버와 Oracle 버전이 모두 있습니다.

---

Java 기반 의 오픈 소스 도구 liquibase 를 언급 한 사람이 아무도 없으며 jdbc를 지원하는 거의 모든 데이터베이스에서 작동해야합니다. 레일과 비교하여 ruby ​​대신 xml을 사용하여 스키마 변경을 수행합니다. 도메인 특정 언어에 대해 XML을 싫어하지만 XML의 가장 멋진 장점은 liquibase가 다음과 같은 특정 작업을 롤백하는 방법을 알고 있다는 것입니다.

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

그래서 당신은 이것을 스스로 처리 할 필요가 없습니다.

순수 SQL 문 또는 데이터 가져 오기도 지원됩니다.

---

대부분의 데이터베이스 엔진은 데이터베이스를 파일로 덤프하는 것을 지원해야합니다. 어쨌든 MySQL은 알고 있습니다. 이것은 텍스트 파일 일 뿐이므로 Subversion 또는 사용하는 모든 파일에 제출할 수 있습니다. 파일에서도 diff를 실행하는 것이 쉽습니다.

---

If you're using SQL Server it would be hard to beat Data Dude (aka the Database Edition of Visual Studio). Once you get the hang of it, doing a schema compare between your source controlled version of the database and the version in production is a breeze. And with a click you can generate your diff DDL.

There's an instructional video on MSDN that's very helpful.

I know about DBMS_METADATA and Toad, but if someone could come up with a Data Dude for Oracle then life would be really sweet.

---

Have your initial create table statements in version controller, then add alter table statements, but never edit files, just more alter files ideally named sequentially, or even as a "change set", so you can find all the changes for a particular deployment.

The hardiest part that I can see, is tracking dependencies, eg, for a particular deployment table B might need to be updated before table A.

---

For Oracle, I use Toad, which can dump a schema to a number of discrete files (e.g., one file per table). I have some scripts that manage this collection in Perforce, but I think it should be easily doable in just about any revision control system.

---

Take a look at the oracle package DBMS_METADATA.

In particular, the following methods are particularly useful:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Once you are familiar with how they work (pretty self explanatory) you can write a simple script to dump the results of those methods into text files that can be put under source control. Good luck!

Not sure if there is something this simple for MSSQL.

---

I write my db release scripts in parallel with coding, and keep the release scripts in a project specific section in SS. If I make a change to the code that requires a db change, then I update the release script at the same time. Prior to release, I run the release script on a clean dev db (copied structure wise from production) and do my final testing on it.

---

I've done this off and on for years -- managing (or trying to manage) schema versions. The best approaches depend on the tools you have. If you can get the Quest Software tool "Schema Manager" you'll be in good shape. Oracle has its own, inferior tool that is also called "Schema Manager" (confusing much?) that I don't recommend.

Without an automated tool (see other comments here about Data Dude) then you'll be using scripts and DDL files directly. Pick an approach, document it, and follow it rigorously. I like having the ability to re-create the database at any given moment, so I prefer to have a full DDL export of the entire database (if I'm the DBA), or of the developer schema (if I'm in product-development mode).

---

PLSQL Developer, a tool from All Arround Automations, has a plugin for repositories that works OK ( but not great) with Visual Source Safe.

From the web:

The Version Control Plug-In provides a tight integration between the PL/SQL Developer IDE >>and any Version Control System that supports the Microsoft SCC Interface Specification. >>This includes most popular Version Control Systems such as Microsoft Visual SourceSafe, >>Merant PVCS and MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

---

ER Studio allows you to reverse your database schema into the tool and you can then compare it to live databases.

Example: Reverse your development schema into ER Studio -- compare it to production and it will list all of the differences. It can script the changes or just push them through automatically.

Once you have a schema in ER Studio, you can either save the creation script or save it as a proprietary binary and save it in version control. If you ever want to go back to a past version of the scheme, just check it out and push it to your db platform.

---

There's a PHP5 "database migration framework" called Ruckusing. I haven't used it, but the examples show the idea, if you use the language to create the database as and when needed, you only have to track source files.

---

You can use Microsoft SQL Server Data Tools in visual studio to generate scripts for database objects as part of a SQL Server Project. You can then add the scripts to source control using the source control integration that is built into visual studio. Also, SQL Server Projects allow you verify the database objects using a compiler and generate deployment scripts to update an existing database or create a new one.

---

We've used MS Team System Database Edition with pretty good success. It integrates with TFS version control and Visual Studio more-or-less seamlessly and allows us to manages stored procs, views, etc., easily. Conflict resolution can be a pain, but version history is complete once it's done. Thereafter, migrations to QA and production are extremely simple.

It's fair to say that it's a version 1.0 product, though, and is not without a few issues.

---

Schema Compare for Oracle is a tool specifically designed to migrate changes from our Oracle database to another. Please visit the URL below for the download link, where you will be able to use the software for a fully functional trial.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

---

In the absence of a VCS for table changes I've been logging them in a wiki. At least then I can see when and why it was changed. It's far from perfect as not everyone is doing it and we have multiple product versions in use, but better than nothing.

---

I'd recommend one of two approaches. First, invest in PowerDesigner from Sybase. Enterprise Edition. It allows you to design Physical datamodels, and a whole lot more. But it comes with a repository that allows you to check in your models. Each new check in can be a new version, it can compare any version to any other version and even to what is in your database at that time. It will then present a list of every difference and ask which should be migrated… and then it builds the script to do it. It’s not cheap but it’s a bargain at twice the price and it’s ROI is about 6 months.

The other idea is to turn on DDL auditing (works in Oracle). This will create a table with every change you make. If you query the changes from the timestamp you last moved your database changes to prod to right now, you’ll have an ordered list of everything you’ve done. A few where clauses to eliminate zero-sum changes like create table foo; followed by drop table foo; and you can EASILY build a mod script. Why keep the changes in a wiki, that’s double the work. Let the database track them for you.

---

Two book recommendations: "Refactoring Databases" by Ambler and Sadalage and "Agile Database Techniques" by Ambler.

Someone mentioned Rails Migrations. I think they work great, even outside of Rails applications. I used them on an ASP application with SQL Server which we were in the process of moving to Rails. You check the migration scripts themselves into the VCS. Here's a post by Pragmatic Dave Thomas on the subject.

참고URL : https://stackoverflow.com/questions/308/is-there-a-version-control-system-for-database-structure-changes