Veritabanı yapısı değişiklikleri için bir sürüm kontrol sistemi var mı?

Sık sık aşağıdaki problemle karşılaşıyorum.

Veritabanında yeni tablolar veya sütunlar gerektiren bir projede bazı değişiklikler üzerinde çalışıyorum. Veritabanı değişikliklerini yapıp çalışmalarıma devam ediyorum. Genellikle, canlı sistemde kopyalanabilmeleri için değişiklikleri not etmeyi hatırlıyorum. Ancak, neyi değiştirdiğimi her zaman hatırlamıyorum ve her zaman yazmayı da hatırlamıyorum.

Bu yüzden, canlı sisteme bir baskı yapıyorum ve yok olduğuna dair büyük, bariz bir hata alıyorum NewColumnX.

Bu durum için en iyi uygulama olmasa da, veritabanları için bir sürüm kontrol sistemi var mı? Belirli veritabanı teknolojisi umrumda değil. Sadece var olup olmadığını bilmek istiyorum. MS SQL Server ile çalışırsa, harika.

Ruby on Rails'de, veritabanını değiştirmek için hızlı bir komut dosyası olan bir geçiş kavramı vardır .

DB sürümünü artırma kuralları (sütun ekleme gibi) ve sürümü düşürme kuralları (bir sütunu kaldırma gibi) içeren bir geçiş dosyası oluşturursunuz. Her geçiş numaralandırılır ve bir tablo mevcut db sürümünüzün kaydını tutar.

İçin yukarı göç sürümüne bakar ve gerektiğinde komut dosyalarını geçerlidir: "migrate db", adlı bir komutunu çalıştırın. Benzer şekilde aşağı göç edebilirsiniz.

Taşıma komut dosyalarının kendileri bir sürüm kontrol sisteminde tutulur - veritabanını her değiştirdiğinizde yeni bir komut dosyasını kontrol edersiniz ve herhangi bir geliştirici bunu yerel veritabanlarını en son sürüme getirmek için uygulayabilir.

Veritabanını oluşturmak için kaynak dosyaları kullandığım için biraz eski kafalıyım. Aslında 2 dosya vardır - proje-veritabanı.sql ve proje-güncellemeleri.sql - ilki şema ve kalıcı veriler için ve ikincisi değişiklikler için. Tabii ki ikisi de kaynak kontrolü altında.

Veritabanı değiştiğinde, önce proje-veritabanı.sql'deki ana şemayı güncelliyorum, daha sonra ilgili bilgileri proje-Updates.sql'e, örneğin ALTER TABLE deyimlerine kopyalıyorum. Daha sonra güncellemeleri geliştirme veritabanına uygulayabilir, test edebilir, iyi bitene kadar yineleyebilirim. Ardından dosyaları iade edin, tekrar test edin ve üretime başvurun.

Ayrıca, genellikle db - Config'de bir tablom var - örneğin:

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: $');

Ardından güncelleme bölümüne şunları ekliyorum:

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

db_versionTek veritabanı yeniden edildiğinde değişti alır ve db_revisionbana db başlangıca kapalı ne kadar uzakta olduğunu bir göstergesidir.

Güncellemeleri kendi ayrı dosyalarında tutabilirdim, ancak hepsini bir araya getirmeyi ve ilgili bölümleri çıkarmak için kes ve yapıştır özelliğini kullanmayı seçtim. Biraz daha temizlik gerekiyor, yani onları dondurmak için $ Revision 1.1 $ 'dan': 'öğesini kaldırın.

MyBatis (eski adıyla iBatis), komut satırında kullanım için bir şema taşıma aracına sahiptir . Java ile yazılmış olsa da herhangi bir proje ile kullanılabilir.

İyi bir veritabanı değişikliği yönetimi uygulaması elde etmek için birkaç temel hedef belirlememiz gerekir. Bu nedenle, MyBatis Schema Migration System (veya kısaca MyBatis Migrations) şunları arar:

• Yeni veya mevcut herhangi bir veritabanıyla çalışın
• Kaynak kontrol sisteminden yararlanın (örn. Subversion)
• Eşzamanlı geliştiricilerin veya ekiplerin bağımsız olarak çalışmasını sağlayın
• Çatışmaların çok görünür ve kolayca yönetilebilir olmasına izin verin
• İleriye ve geriye doğru geçişe izin verin (sırasıyla evrim geçirin, ilerleyin)
• Veritabanının mevcut durumunu kolay erişilebilir ve anlaşılır hale getirin
• Erişim ayrıcalıklarına veya bürokrasiye rağmen geçişleri etkinleştirin
• Herhangi bir metodoloji ile çalışın
• İyi ve tutarlı uygulamaları teşvik eder

Redgate'in SQL Kaynak Kontrolü adlı bir ürünü vardır . TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce ve Git ile entegre olur.

SQL delta'yı şiddetle tavsiye ederim . Özelliğimi kodlamayı bitirdiğimde diff komut dosyalarını oluşturmak için kullanıyorum ve bu komut dosyalarını kaynak kontrol aracıma (Mercurial :))

Hem SQL sunucusu hem de Oracle sürümü var.

Hiç kimsenin Java tabanlı ve jdbc'yi destekleyen hemen hemen her veritabanı için çalışması gereken açık kaynak aracı sıvısından bahsetmediğini merak ediyorum . Raylarla karşılaştırıldığında, şema değişikliklerini gerçekleştirmek için ruby ​​yerine xml kullanır. Etki alanına özgü diller için xml'den hoşlanmadığım halde, xml'nin en harika avantajı, liquibase'in,

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

Yani bunu kendi başına halletmene gerek yok

Saf sql ifadeleri veya veri aktarımları da desteklenir.

Çoğu veritabanı motoru, veritabanınızı bir dosyaya dökmeyi desteklemelidir. MySQL'in yaptığını biliyorum. Bu sadece bir metin dosyası olacak, böylece onu Subversion'a gönderebilirsin ya da ne kullanırsan kullan. Dosyalarda bir fark çalıştırmak da kolay olurdu.

SQL Server kullanıyorsanız, Data Dude'u (diğer adıyla Visual Studio'nun Veritabanı Sürümü) yenmek zor olacaktır. Bir kez asıldığınızda, veritabanının kaynak kontrollü sürümü ile üretimdeki sürüm arasında bir şema karşılaştırması yapmak çok kolay. Ve bir tıklama ile diff DDL'nizi oluşturabilirsiniz.

MSDN'de çok yardımcı olan bir eğitici video var.

DBMS_METADATA ve Toad hakkında bilgim var, ancak birisi Oracle için bir Data Dude bulabilirse, hayat gerçekten çok tatlı olurdu.

İlk oluşturma tablosu ifadelerinizi sürüm denetleyicisinde bulundurun, sonra tablo deyimleri ekleyin, ancak dosyaları asla düzenlemeyin, yalnızca ideal olarak sıralı olarak adlandırılan dosyaları daha fazla değiştirin veya hatta bir "değişiklik kümesi" olarak belirli bir dağıtım için tüm değişiklikleri bulabilirsiniz.

Görebildiğim en zor kısım bağımlılıkları izlemek, örneğin belirli bir dağıtım tablosu için B tablosundan önce güncellenmesi gerekebilir.

Oracle için, bir şemayı birkaç ayrı dosyaya (örneğin, tablo başına bir dosya) dökebilen Toad kullanıyorum . Bu koleksiyonu Perforce'da yöneten bazı komut dosyalarım var, ancak bunun hemen hemen her revizyon kontrol sisteminde kolayca yapılabilmesi gerektiğini düşünüyorum.

Oracle paketi DBMS_METADATA'ya bir göz atın.

Özellikle aşağıdaki yöntemler özellikle yararlıdır:

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

Nasıl çalıştıklarına aşina olduğunuzda (oldukça açıklayıcı), bu yöntemlerin sonuçlarını kaynak kontrolü altına alınabilecek metin dosyalarına dökmek için basit bir komut dosyası yazabilirsiniz. İyi şanslar!

MSSQL için bu kadar basit bir şey olup olmadığından emin değilim.

Db sürüm betiklerimi kodlamaya paralel olarak yazıyorum ve sürüm betiklerini SS'de projeye özel bir bölümde tutuyorum. Kodda bir db değişikliği gerektiren bir değişiklik yaparsam, aynı zamanda yayın komut dosyasını da güncellerim. Yayınlanmadan önce, yayın komut dosyasını temiz bir geliştirici veritabanında (üretimden yapı olarak kopyalanmış) çalıştırıyorum ve üzerinde son testimi yapıyorum.

Bunu yıllardır aralıksız yaptım - şema sürümlerini yönetiyorum (veya yönetmeye çalışıyorum). En iyi yaklaşımlar, sahip olduğunuz araçlara bağlıdır. Quest Software aracını "Schema Manager" alabilirseniz, iyi durumda olacaksınız. Oracle'ın tavsiye etmediğim "Schema Manager" (kafa karıştırıcı çok mu?) Olarak da adlandırılan kendi alt aracı var.

Otomatikleştirilmiş bir araç olmadan (Data Dude hakkındaki diğer yorumlara bakın), komut dosyalarını ve DDL dosyalarını doğrudan kullanıyor olacaksınız. Bir yaklaşım seçin, belgeleyin ve titizlikle uygulayın. Veritabanını herhangi bir anda yeniden oluşturma yeteneğine sahip olmayı seviyorum, bu nedenle tüm veritabanının (DBA isem) veya geliştirici şemasının (üründe isem) tam DDL dışa aktarımını tercih ediyorum. -Geliştirme Modu).

All Arround Automations'tan bir araç olan PLSQL Developer, Visual Source Safe ile iyi çalışan (ancak harika olmayan) depolar için bir eklentiye sahiptir.

Web'den:

Sürüm Kontrolü Eklentisi, PL / SQL Developer IDE >> ile Microsoft SCC Arayüz Spesifikasyonunu destekleyen herhangi bir Sürüm Kontrol Sistemi arasında sıkı bir entegrasyon sağlar. >> Bu, Microsoft Visual SourceSafe, >> Merant PVCS ve MKS Source Integrity gibi en popüler Sürüm Kontrol Sistemlerini içerir.

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

ER Studio , veritabanı şemanızı araca çevirmenize olanak tanır ve ardından bunu canlı veritabanlarıyla karşılaştırabilirsiniz.

Örnek: Geliştirme şemanızı ER Studio'ya ters çevirin - üretimle karşılaştırın ve tüm farklılıkları listeleyecektir. Değişiklikleri komut dosyası haline getirebilir veya yalnızca otomatik olarak iletebilir.

ER Studio'da bir şema oluşturduğunuzda, oluşturma komut dosyasını kaydedebilir veya özel bir ikili dosya olarak kaydedebilir ve sürüm kontrolünde kaydedebilirsiniz. Şemanın eski bir sürümüne geri dönmek isterseniz, sadece kontrol edin ve db platformunuza aktarın.

Ruckusing adında bir PHP5 "veritabanı taşıma çerçevesi" var. Bunu kullanmadım, ancak örnekler fikri gösteriyor, veritabanını gerektiği gibi ve gerektiğinde oluşturmak için dili kullanırsanız, yalnızca kaynak dosyaları izlemeniz gerekir.

SQL Server Projesinin bir parçası olarak veritabanı nesneleri için komut dosyaları oluşturmak için Visual Studio'da Microsoft SQL Server Veri Araçlarını kullanabilirsiniz . Daha sonra görsel stüdyoya yerleştirilen kaynak kontrol entegrasyonunu kullanarak komut dosyalarını kaynak kontrolüne ekleyebilirsiniz. Ayrıca, SQL Server Projeleri, bir derleyici kullanarak veritabanı nesnelerini doğrulamanıza ve mevcut bir veritabanını güncellemek veya yeni bir tane oluşturmak için dağıtım betikleri oluşturmanıza olanak tanır.

Biz kullandım MS Team sistem veritabanı Edition'ı oldukça iyi bir başarı ile. TFS sürüm kontrolü ve Visual Studio ile az çok sorunsuz bir şekilde entegre olur ve depolanan işlemleri, görünümleri vb. Kolayca yönetmemize olanak tanır. Uyuşmazlık çözümü bir sorun olabilir, ancak sürüm geçmişi tamamlandığında tamamlanır. Bundan sonra, QA'ya geçişler ve üretim son derece basittir.

Bununla birlikte, bunun bir sürüm 1.0 ürünü olduğunu söylemek doğru ve birkaç sorun olmadan değil.

Schema Compare for Oracle, değişiklikleri Oracle veritabanımızdan diğerine geçirmek için özel olarak tasarlanmış bir araçtır. Yazılımı tamamen işlevsel bir deneme için kullanabileceğiniz indirme bağlantısı için lütfen aşağıdaki URL'yi ziyaret edin.

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

Tablo değişiklikleri için bir VCS yokluğunda, bunları bir wiki'ye kaydediyordum. En azından o zaman ne zaman ve neden değiştirildiğini anlayabiliyorum. Herkes yapmadığı ve kullanımda olan birden fazla ürün sürümümüz olduğu için mükemmel olmaktan uzak, ama hiç yoktan iyidir.

İki yaklaşımdan birini tavsiye ederim. İlk önce PowerDesigner'a yatırım yapın . Kurumsal Sürüm. Fiziksel veri modelleri ve çok daha fazlasını tasarlamanıza olanak tanır. Ancak modellerinizi kontrol etmenize izin veren bir havuzla birlikte gelir. Her yeni iade yeni bir sürüm olabilir, herhangi bir sürümü başka bir sürümle ve hatta o sırada veritabanınızda bulunanlarla karşılaştırabilir. Daha sonra her farkın bir listesini sunacak ve hangisinin taşınması gerektiğini soracaktır… ve bunu yapmak için betiği oluşturacaktır. Ucuz değil, ancak iki katı fiyata bir pazarlık ve yatırım getirisi yaklaşık 6 ay.

Diğer fikir, DDL denetimini açmaktır (Oracle'da çalışır). Bu, yaptığınız her değişiklikle bir tablo oluşturacaktır. Veritabanı değişikliklerinizi şu anda prod'a en son taşıdığınız zaman damgasından gelen değişiklikleri sorgularsanız, yaptığınız her şeyin sıralı bir listesine sahip olursunuz. Tablo foo oluşturmak gibi sıfır toplamlı değişiklikleri ortadan kaldıran birkaç yerde; ardından table foo açılır; ve KOLAYCA bir mod betiği oluşturabilirsiniz. Neden değişiklikleri bir wikide tutmak, bu işin iki katı. Veritabanının bunları sizin için izlemesine izin verin.

İki kitap önerisi: Ambler ve Sadalage'ın "Veritabanlarını Yeniden Düzenleme" ve Ambler tarafından "Çevik Veritabanı Teknikleri".

Biri Rails Migration'dan bahsetti. Bence Rails uygulamalarının dışında bile harika çalışıyorlar. Bunları Rails'e geçme sürecinde olduğumuz SQL Server ile bir ASP uygulamasında kullandım. VCS'ye geçiş komut dosyalarını kontrol edersiniz. İşte Pragmatik Dave Thomas'ın konuyla ilgili bir yazısı .