SQL Server veritabanını sürümlendirme


315

Veritabanlarımı sürüm kontrolü altına almak istiyorum. Beni başlatmak için herhangi bir tavsiye veya tavsiye makalesi olan var mı?

Her zaman orada en azından bazı veriler olmasını isteyeceğim ( bahsettiğimiz gibi: kullanıcı türleri ve yöneticiler). Ayrıca genellikle performans ölçümleri için geniş bir oluşturulan test verisi koleksiyonu isteyeceğim.


Ayrıca bu teknik incelemeye bir göz atın; Veritabanı Sürüm Kontrolü için Kesin Kılavuz www3.dbmaestro.com/…
DBAstep

Yanıtlar:


179

Martin Fowler bu konuda en sevdiğim makaleyi yazdı: http://martinfowler.com/articles/evodb.html . Üretim veritabanımı yükseltmenin kolay bir yolunu istediğim için şema dökümlerini sürüm kontrolü altına almamayı tercih ediyorum.

Tek bir üretim veritabanı örneğine sahip olacağım bir web uygulaması için iki teknik kullanıyorum:

Veritabanı Yükseltme Komut Dosyaları

Şemayı sürüm N'den N + 1'e taşımak için gerekli DDL'yi içeren bir dizi veritabanı yükseltme komut dosyaları. (Bunlar sürüm kontrol sisteminize girer.) Bir _version_history_ tablosu, gibi bir şey

create table VersionHistory (
    Version int primary key,
    UpgradeStart datetime not null,
    UpgradeEnd datetime
    );

yeni sürüme karşılık gelen bir yükseltme komut dosyası her çalıştığında yeni bir giriş alır.

Bu, veritabanı şemasının hangi sürümünün var olduğunu ve veritabanı yükseltme komut dosyalarının yalnızca bir kez çalıştırıldığını görmeyi kolaylaştırır. Yine, bunlar veritabanı dökümü değil . Bunun yerine, her komut dosyası bir sürümden diğerine geçmek için gerekli değişiklikleri temsil eder . Bunlar, üretim veritabanınıza "yükseltmek" için uyguladığınız komut dosyasıdır.

Geliştirici Korumalı Alan Senkronizasyonu

  1. Bir üretim veritabanını yedeklemek, sterilize etmek ve küçültmek için bir komut dosyası. Üretim DB'sine yapılan her yükseltmeden sonra bunu çalıştırın.
  2. Bir geliştiricinin iş istasyonundaki yedeklemeyi geri yüklemek (ve gerekirse değiştirmek) için bir komut dosyası. Her geliştirici bu komut dosyasını üretim DB'sine her yükseltmeden sonra çalıştırır.

Bir uyarı: Otomatik testlerim şema doğru ama boş bir veritabanına karşı çalışır;


16
Tam şema komut dosyalarını denetleyen sürüm, başvuru amacıyla çok yararlıdır. Örneğin, ALTER PROCEDURE ifadesine bakarak saklı yordamda tam olarak nelerin değiştiğini görmek mümkün değildir.
Constantin

12
Yeni yükseltme komut dosyalarını çalıştırdıktan sonra tam DB şemasını boşaltma (ve sürümlendirme), bilgileri derleme / dağıtma işleminizdeki diğer araçlar için de kullanılabilir hale getirmenin iyi bir yoludur. Ayrıca, bir komut dosyasında tam şemanın olması, tüm geçiş adımlarını gerçekleştirmeden yeni bir veritabanını "döndürmek" anlamına gelir. Ayrıca, mevcut sürümü birikmiş önceki sürümlere göre ayırmayı da mümkün kılar.
mlibby

2
Yükseltme komut dosyalarını kaynak denetimine koyduğunuzu mı söylüyorsunuz, somun oraya geri dönmez mi?
AK

9
Tam bir oluşturma ve bırakma komut dosyası yanı sıra güncel db örnekleri güncelleştirmek için delta komut dosyaları korumak için bir alışkanlık var. Her ikisi de sürüm kontrolüne girer. Delta komut dosyaları, düzeltme numaralarına göre adlandırılır. Bu şekilde, bir güncelleme komut dosyası ile db yama işlemini otomatikleştirmek kolaydır.
nikc.org

1
@ nikc.org'un yanıtı, otomasyon için taahhüt sonrası kancalar.
Silviu-Marian

45

Red Gate'in SQL Compare ürünü, yalnızca nesne düzeyinde karşılaştırmalar yapmanıza ve bundan değişiklik komut dosyaları oluşturmanıza izin vermekle kalmaz, aynı zamanda veritabanı nesnelerinizi bir [objectname] .sql oluşturma ile nesne türüne göre düzenlenmiş bir klasör hiyerarşisine dışa aktarmanıza olanak tanır. bu dizinlerde nesne başına komut dosyası. Nesne türü hiyerarşisi aşağıdaki gibidir:

\ İşlevler
\ Güvenlik
\ Güvenlik \ Roller
\ Güvenlik \ Şemalar
\ Güvenlik \ Kullanıcılar
\ Saklı Yordamlar
\ Tablolar

Değişiklik yaptıktan sonra komut dosyalarınızı aynı kök dizine dökerseniz, SVN deponuzu güncellemek ve her nesnenin çalışma geçmişini ayrı ayrı tutmak için bunu kullanabilirsiniz.


6
Az önce tanımladığınız SQL Compare davranışını SSMS'ye entegre eden ve SVN ve TFS'ye bağlanan SQL Source Control'ü çıkardık. Bu soruya ne yaptığını daha ayrıntılı olarak açıklayan ayrı bir cevap ekledim. red-gate.com/products/SQL_Source_Control/index.htm
David Atkinson

39

Bu kalkınmayı çevreleyen "zor problemlerden" biridir. Bildiğim kadarıyla mükemmel bir çözüm yok.

Veriyi değil, sadece veritabanı yapısını saklamanız gerekiyorsa, veritabanını SQL sorguları olarak dışa aktarabilirsiniz. (Enterprise Manager'da: Veritabanına sağ tıklayın -> SQL betiği oluştur. Seçenekler sekmesinde "nesne başına bir dosya oluştur" seçeneğini ayarlamanızı öneririm) Daha sonra bu metin dosyalarını svn'ye bağlayabilir ve svn'nin diff ve log işlevlerini kullanabilirsiniz.

Bu birkaç parametre alır ve veritabanını ayarlar bir Toplu komut dosyası ile birlikte var. Ayrıca, kullanıcı türleri ve yönetici kullanıcı gibi varsayılan verileri giren bazı ek sorgular ekledim. (Bu konuda daha fazla bilgi edinmek isterseniz, bir şeyler gönderin ve betiği erişilebilir bir yere koyabilirim)

Tüm verileri de saklamanız gerekiyorsa, veritabanını yedeklemenizi ve karşılaştırmaları yapmak için Redgate ( http://www.red-gate.com/ ) ürünlerini kullanmanızı öneririm . Ucuz gelmiyorlar, ama her kuruşuna değer.


1
verilerle ilgili - tüm DB'nizin (veriler dahil) sürümlerini kaydetmek için OffScale DataGrove kullanabilirsiniz . Daha sonra bunu DB'nizin kırmızı kapının ürünüyle karşılaştırılabilecek iki sanal kopyasını oluşturmak için kullanabilirsiniz. Ayrıca, test verileri oluşturma ihtiyacından da tasarruf sağlar - DB'nin farklı test senaryolarıyla (tekrar, tüm DB'nin tam, sanal kopyaları) eşleşmesi için kaydedebilirsiniz
Taichman

1
"Nesne başına bir dosya" seçeneğini kullanırsanız, veritabanı komut dosyalarını çalıştırmak için hangi sırayı nasıl öğrenirsiniz?
Jamie Kitson

@Taichman: DataGrove, SQL sunucusunu desteklemiyor gibi görünüyor ve bu nedenle soru ile ilgisi yok.
Neolisk

38

İlk olarak, sizin için doğru olan sürüm kontrol sistemini seçmelisiniz:

  • Merkezi Sürüm Kontrol sistemi - kullanıcıların dosyalar üzerinde çalışmadan önce / sonra teslim aldıkları / teslim ettikleri ve dosyaların tek bir merkezi sunucuda tutulduğu standart bir sistem

  • Dağıtılmış Sürüm Kontrol sistemi - deponun klonlandığı ve her klonun aslında deponun tam yedeği olduğu bir sistemdir, bu nedenle herhangi bir sunucu çökerse, geri yüklemek için herhangi bir klonlanmış depo, ihtiyaçlarınız için doğru sistemi seçtikten sonra kullanılabilir , her sürüm kontrol sisteminin çekirdeği olan havuzu kurmanız gerekir. Tüm bunlar aşağıdaki makalede açıklanmıştır: http://solutioncenter.apexsql.com/sql-server-source-control-part-i- anlama -Source kontrol-temelleri /

Bir havuz kurduktan sonra ve merkezi sürüm kontrol sisteminde bir çalışma klasörü olması durumunda, bu makaleyi okuyabilirsiniz . Aşağıdakileri kullanarak bir geliştirme ortamında kaynak kontrolünün nasıl kurulacağını gösterir:

  • MSSCCI sağlayıcısı aracılığıyla SQL Server Management Studio,

  • Visual Studio ve SQL Server Veri Araçları

  • Üçüncü taraf bir araç ApexSQL Kaynak Kontrolü

24

Burada Red Gate'te veritabanınızı bir TFS veya SVN deposuna bağlamak için SQL Compare teknolojisini kullanan bir SQL Kaynak Kontrolü aracı sunuyoruz . Bu araç SSMS ile bütünleşir ve normalde yaptığınız gibi çalışmanıza izin verir, ancak artık nesneleri işleme koymanıza izin verir.

Taşıma tabanlı bir yaklaşım için (otomatik dağıtımlar için daha uygundur), Visual Studio projesi olarak bir dizi artımlı komut dosyası oluşturan ve yöneten SQL Değişim Otomasyonu (eski adıyla ReadyRoll) sunuyoruz .

SQL Source Control'de statik veri tabloları belirtmek mümkündür. Bunlar kaynak denetiminde INSERT ifadeleri olarak saklanır.

Test verileri hakkında konuşuyorsanız, test verilerini bir araçla veya tanımladığınız bir dağıtım sonrası komut dosyası aracılığıyla oluşturmanızı veya yalnızca bir üretim yedeklemesini geliştirici ortamına geri yüklemenizi öneririz.


İlginç ürün (piyasada bir boşluk biraz) ama "CREATE ..." olarak saklanan deltalar beni korkutuyor. Nasıl dallanıyor / birleşiyorsunuz?
annakata

1
Nesne tanımlarını CREATE olarak depolarız, ancak 'en son' alırsanız veya örneğin, eşitleme komut dosyaları oluşturmak için SQL Compare Pro'yu kullanırsanız, bunlar ALTER gibi uygun komutlarla değiştirilir. Dallamak veya birleştirmek için, kaynak kontrol sisteminizi şu anda yaptığınız gibi kullanmanız yeterlidir.
David Atkinson

Bu cevap Dane'in iki yıl önce verdiği cevabının bir kopyası.
WonderWorker

Farklı bir cevap. SQL Compare kontrol veritabanlarını sürüm olarak kullanmazken, SQL Source Control bunun için özel olarak tasarlanmıştır.
David Atkinson

21

Liquibase'e ( http://www.liquibase.org/ ) bakmak isteyebilirsiniz . Aracın kendisini kullanmasanız bile, veritabanı değişiklik yönetimi veya yeniden düzenleme kavramlarını oldukça iyi işler.


Sürekli dağıtım için tek bir şubede 5 dağıtılmış takımda Liquibase kullanıyoruz ve harika çalışıyor. Birçok farklı ortamda kurulu 10+ veritabanı uygulamamız var. Bunu şema, dizinleme, bölümleme, kod, arama verileri, gruplar ve grup izinlerini yönetmek için kullanırız. Oracle, Postgresql ve MSSQL için kullanıyoruz.
Peter Henell

Eğer intro dayalı doğru anlamak, SQL yerine nesneleri ilan etmek için bazı tescilli xml dil bilmek gerektirir? Hayranı değil.
JDPeckham

19

RedGate araçlarını tavsiye eden herkes için ek bir öneri ve bir uyarı ile +1.

SqlCompare ayrıca iyi belgelenmiş bir API'ye sahiptir: böylece, kaynak kontrollü komut dosyaları klasörünüzü check-in sırasında bir CI entegrasyon testi veritabanıyla senkronize eden bir konsol uygulaması yazabilirsiniz, böylece birisi komut dosyalarını klasöründeki şemada bir değişiklik kontrol ettiğinde eşleşen uygulama kodu değişikliği ile birlikte otomatik olarak dağıtılır. Bu, yerel db'deki değişiklikleri paylaşılan bir geliştirme veritabanına (yaklaşık yarımız, sanırım :)) kadar ilerletmeyi unutan geliştiricilerle boşluğu kapatmaya yardımcı olur.

Bir uyarı, komut dosyasıyla yazılmış bir çözümle veya başka bir şekilde, RedGate araçlarının, soyutlamanın altında yatan SQL gerçeklerini unutmanın kolay olduğu kadar pürüzsüz olmasıdır. Bir tablodaki tüm sütunları yeniden adlandırırsanız, SqlCompare eski sütunları yeni sütunlarla eşleştiremez ve tablodaki tüm verileri bırakır. Uyarılar üretecek, ancak insanların bunu geçtiğini gördüm. Burada, DB sürümlerini otomatikleştirebileceğiniz ve yükseltebileceğiniz genel bir nokta var, soyutlamalar çok sızdı.


Dolayısıyla, hangi sütunları değiştirdiğinizi izleyen ve eski sütun adlarından yeni sütun adlarına yapılan eşleşmeleri hatırlayan bir sistem olmalıdır.
Silvercode

Belirsizliğe sahip olan (ve bu nedenle "geliştirici amacı" unsuruna ihtiyaç duyan) veritabanı değişiklikleri için, taşıma tabanlı bir çözümün uygun çözüm olduğunu akılda tutmak gerekir. Redgate artık bu sürüm oluşturma yaklaşımını karşılayan ReadyRoll'a sahip.
David Atkinson

15

SQL veritabanımızı yönetmek için DBGhost kullanıyoruz . Daha sonra komut dosyalarınızı sürüm denetiminizde yeni bir veritabanı oluşturmaya koyarsınız ve yeni bir veritabanı oluşturur veya varolan herhangi bir veritabanını sürüm denetimindeki şemaya yükseltir. Bu şekilde, değişiklik komut dosyaları oluşturma konusunda endişelenmenize gerek kalmaz (yine de bunu yapabilirsiniz, ancak örneğin bir sütunun veri türünü değiştirmek ve verileri dönüştürmeniz gerekiyorsa).


10 yıldır DbGhost kullandım ve beni asla hayal kırıklığına uğratmadı. Sağladıkları destek hiçbiri ikinci değil
penderi

15

VS 2010 ile Veritabanı projesini kullanın.

  1. Veritabanınızı betimleyin
  2. Komut dosyalarında veya doğrudan db sunucunuzda değişiklik yapma
  3. Veri> Şema Karşılaştırması kullanarak senkronize etme

Mükemmel bir DB sürüm oluşturma çözümü yapar ve DB'leri senkronize etmeyi kolaylaştırır.


2
Evet ama ne yazık ki her seferinde "script" yazmayı hatırlamalısınız. Veritabanını doğrudan güncelleştirirseniz, söz konusu delta için güncelleme komut dosyası oluşturma yeteneğini kaybedersiniz. Yalnızca veritabanı projelerinin sürüm oluşturma için bazı yerleşik işlevleri varsa.
Jez

13

Sahip olduğunuz herhangi bir veritabanını yükseltebilmeniz için veritabanı komut dosyalarını değişiklik komut dosyalarıyla sürüm denetimine kaydetmek iyi bir yaklaşımdır. Ayrıca, tüm değişiklik komut dosyalarını uygulamak zorunda kalmadan tam bir veritabanı oluşturabilmeniz için farklı sürümler için şemalar kaydetmek isteyebilirsiniz. Komut dosyalarının kullanımı, el ile çalışma yapmanız gerekmeyecek şekilde otomatikleştirilmelidir.

Her geliştirici için ayrı bir veritabanı olması ve paylaşılan bir veritabanı kullanmamasının önemli olduğunu düşünüyorum. Bu şekilde geliştiriciler, diğer geliştiricilerden bağımsız olarak test senaryoları ve geliştirme aşamaları oluşturabilir.

Otomatikleştirme aracı, hangi veritabanlarının hangi geliştirme durumunda olduğunu ve hangi tabloların sürüm tarafından kontrol edilebilir veriler içerdiğini söyleyen veritabanı meta verilerini işlemek için araçlara sahip olmalıdır.


12

Ayrıca bir taşıma çözümüne de bakabilirsiniz. Bunlar, veritabanı şemanızı C # kodunda belirtmenize ve MSBuild kullanarak veritabanı sürümünüzü yukarı ve aşağı yuvarlamanıza olanak tanır.

Şu anda DbUp kullanıyorum ve iyi çalışıyor.


11

Hedef ortamınız veya kısıtlamalarınızla ilgili herhangi bir spesifikasyondan bahsetmediniz, bu tamamen uygulanabilir olmayabilir ... ancak gelişen bir DB şemasını etkili bir şekilde izlemenin bir yolunu arıyorsanız ve kullanma fikrini olumsuz bulmuyorsanız Ruby, ActiveRecord'un taşıma işlemleri hemen karşınızda.

Taşıma işlemleri, bir Ruby DSL kullanarak veritabanı dönüşümlerini programlı olarak tanımlar; her dönüşüm uygulanabilir veya (genellikle) geri döndürülebilir, böylece DB şemanızın farklı bir sürümüne zaman içinde atlayabilirsiniz. Bu dönüşümleri tanımlayan dosya, diğer herhangi bir kaynak kodu gibi sürüm kontrolüne kontrol edilebilir.

Taşıma işlemleri ActiveRecord'un bir parçası olduğundan , genellikle tam yığın Rails uygulamalarında kullanım bulurlar; ancak ActiveRecord'u Rails'den bağımsız olarak en az çabayla kullanabilirsiniz. AR'nin göçlerini Rails dışında kullanmanın daha ayrıntılı bir tedavisi için buraya bakın .


10

Her veritabanı kaynak kodu kontrolü altında olmalıdır. Eksik olan şey, daha sonra herhangi bir kaynak kontrol sistemine eklenebilen tüm veritabanı nesnelerini - ve "konfigürasyon verilerini" - otomatik olarak dosyalamak için bir araçtır. SQL Server kullanıyorsanız, çözümüm burada: http://dbsourcetools.codeplex.com/ . İyi eğlenceler. - Nathan.


9

Basit.

  1. Temel proje hazır olduğunda, tam veritabanı komut dosyası oluşturmanız gerekir. Bu komut dosyası SVN'ye bağlıdır. İlk versiyon.

  2. Bundan sonra tüm geliştiriciler değişiklik komut dosyaları oluşturur (ALTER ..., yeni tablolar, sprocs, vb.).

  3. Geçerli sürüme ihtiyacınız olduğunda, tüm yeni değişiklik komut dosyalarını yürütmelisiniz.

  4. Uygulama üretime bırakıldığında, 1'e geri dönersiniz (ancak daha sonra elbette ardışık sürümü olacaktır).

Nant, bu değişiklik komut dosyalarını yürütmenize yardımcı olacaktır. :)

Ve Hatırla. Disiplin olduğunda her şey yolunda gidiyor. Veritabanı değişikliğinin her gerçekleştirilmesinde koddaki ilgili işlevler de yerine getirilir.


2
Birkaç yıl sonra diyorum ki: FluentMigrator (veya platformunuz için benzer bir araç) kullanın.
dariol

8

Küçük bir veritabanınız varsa ve her şeyi sürümlendirmek istiyorsanız, bu toplu komut dosyası yardımcı olabilir. Bir MSSQL veritabanı MDF dosyasını Subversion'a ayırır, sıkıştırır ve denetler.

Şemanızı çoğunlukla sürümlendirmek ve yalnızca az miktarda referans veriniz varsa, bunu gerçekleştirmek için muhtemelen SubSonic Migrations'ı kullanabilirsiniz . Bunun yararı, belirli bir sürüme kolayca yukarı veya aşağı geçiş yapabilmenizdir.


8

Kaynak kodu kontrol sistemine yapılan dökümü biraz daha hızlı yapmak için, sysobjects'teki sürüm bilgilerini kullanarak son kez hangi nesnelerin değiştiğini görebilirsiniz.

Kurulum: Sürüm bilgilerini en son denetlediğiniz zamandan itibaren tutmak için her veritabanında aşamalı olarak kontrol etmek istediğiniz bir tablo oluşturun (ilk çalıştırmada boş). Tüm veri yapınızı yeniden taramak istiyorsanız bu tabloyu temizleyin.

IF ISNULL(OBJECT_ID('last_run_sysversions'), 0) <> 0 DROP TABLE last_run_sysversions
CREATE TABLE last_run_sysversions (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

Normal çalışma modu: Bu sql'den sonuçları alabilir ve yalnızca ilgilendikleriniz için sql komut dosyaları oluşturabilir ve bunları seçtiğiniz bir kaynak denetimine alabilirsiniz.

IF ISNULL(OBJECT_ID('tempdb.dbo.#tmp'), 0) <> 0 DROP TABLE #tmp
CREATE TABLE #tmp (
    name varchar(128), 
    id int, base_schema_ver int,
    schema_ver int,
    type char(2)
)

SET NOCOUNT ON

-- Insert the values from the end of the last run into #tmp
INSERT #tmp (name, id, base_schema_ver, schema_ver, type) 
SELECT name, id, base_schema_ver, schema_ver, type FROM last_run_sysversions

DELETE last_run_sysversions
INSERT last_run_sysversions (name, id, base_schema_ver, schema_ver, type)
SELECT name, id, base_schema_ver, schema_ver, type FROM sysobjects

-- This next bit lists all differences to scripts.
SET NOCOUNT OFF

--Renamed.
SELECT 'renamed' AS ChangeType, t.name, o.name AS extra_info, 1 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id
WHERE o.name <> t.name /*COLLATE*/
AND o.type IN ('TR', 'P' ,'U' ,'V')
UNION 

--Changed (using alter)
SELECT 'changed' AS ChangeType, o.name /*COLLATE*/, 
       'altered' AS extra_info, 2 AS Priority
FROM sysobjects o INNER JOIN #tmp t ON o.id = t.id 
WHERE (
   o.base_schema_ver <> t.base_schema_ver
OR o.schema_ver      <> t.schema_ver
)
AND  o.type IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT oi.name 
         FROM sysobjects oi INNER JOIN #tmp ti ON oi.id = ti.id
         WHERE oi.name <> ti.name /*COLLATE*/
         AND oi.type IN ('TR', 'P' ,'U' ,'V')) 
UNION

--Changed (actually dropped and recreated [but not renamed])
SELECT 'changed' AS ChangeType, t.name, 'dropped' AS extra_info, 2 AS Priority
FROM #tmp t
WHERE    t.name IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
AND  t.name IN ( SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Deleted
SELECT 'deleted' AS ChangeType, t.name, '' AS extra_info, 0 AS Priority
FROM #tmp t
WHERE NOT EXISTS (SELECT * FROM sysobjects o
                  WHERE o.id = t.id)
AND t.name NOT IN (  SELECT oi.name /*COLLATE*/ FROM sysobjects oi
         WHERE NOT EXISTS (SELECT * FROM #tmp ti
                           WHERE oi.id = ti.id)
         AND   oi.type  IN ('TR', 'P' ,'U' ,'V'))
UNION

--Added
SELECT 'added' AS ChangeType, o.name /*COLLATE*/, '' AS extra_info, 4 AS Priority
FROM sysobjects o
WHERE NOT EXISTS (SELECT * FROM #tmp t
                  WHERE o.id = t.id)
AND      o.type  IN ('TR', 'P' ,'U' ,'V')
AND  o.name NOT IN ( SELECT ti.name /*COLLATE*/ FROM #tmp ti
         WHERE NOT EXISTS (SELECT * FROM sysobjects oi
                           WHERE oi.id = ti.id))
ORDER BY Priority ASC

Not: Veritabanlarınızdan herhangi birinde standart olmayan bir harmanlama kullanırsanız /* COLLATE */, veritabanı harmanlamanızla değiştirmeniz gerekir . yaniCOLLATE Latin1_General_CI_AI


8

Uygulamamızın birden fazla RDBMS'de çalışması gerektiğinden, şema tanımımızı veritabanı nötr Tork formatını (XML) kullanarak sürüm kontrolünde saklarız . Ayrıca veritabanımızın referans verilerini XML biçiminde aşağıdaki şekilde kontrol ediyoruz (burada "İlişki" referans tablolarından biridir):

  <Relationship RelationshipID="1" InternalName="Manager"/>
  <Relationship RelationshipID="2" InternalName="Delegate"/>
  etc.

Daha sonra şemayı yükseltmek ve veritabanının X sürümünden X + 1 sürümüne geçmek için gerekli olan veri yükseltme komut dosyalarını oluşturmak için evde kullanılan araçları kullanırız.


7

Veritabanı şemasını saklamıyoruz, değişiklikleri veritabanında saklıyoruz. Yaptığımız şema değişikliklerini saklamaktır, böylece veritabanının herhangi bir sürümü için bir değişiklik komut dosyası oluşturur ve bunu müşterilerimizin veritabanlarına uygularız. Bu komut dosyasını okuyabilen ve hangi güncelleştirmelerin uygulanması gerektiğini bilen ana uygulamamızla dağıtılan bir veritabanı yardımcı programı uygulaması yazdım. Ayrıca, görünümleri ve saklı yordamları gerektiği gibi yenilemek için yeterli akıllılığa sahiptir.


7

Bir x64 platformuna geçtikten ve eski sürümümüz taşıma işleminden sonra SQL veritabanımızı sürümlendirmeye ihtiyacımız vardı. Tüm SQL nesnelerini bir klasöre eşlemek için SQLDMO kullanılan bir C # uygulaması yazdık:

                Kök
                    Sunucu adı
                       Veri tabanı ismi
                          Şema Nesneleri
                             Veritabanı Tetikleyicileri *
                                .ddltrigger.sql
                             Fonksiyonlar
                                ..function.sql
                             Güvenlik
                                Roller
                                   Uygulama Rolleri
                                      .approle.sql
                                   Veritabanı Rolleri
                                      .role.sql
                                Şemalar *
                                   .schema.sql
                                Kullanıcılar
                                   .user.sql
                             Depolama
                                Tam Metin Kataloglar *
                                   .fulltext.sql
                             Saklı Yordamlar
                                ..proc.sql
                             Eş anlamlı*
                                .synonym.sql
                             Tablolar
                                ..table.sql
                                Kısıtlamalar
                                   ... chkconst.sql
                                   ... defconst.sql
                                endeksleri
                                   ... index.sql
                                Anahtarlar
                                   ... fkey.sql
                                   ... pkey.sql
                                   ... ukey.sql
                                tetikleyiciler
                                   ... trigger.sql
                             Türleri
                                Kullanıcı Tanımlı Veri Türleri
                                   ..uddt.sql
                                XML Şeması Koleksiyonları *
                                   ..xmlschema.sql
                             Görüntüleme
                                ..view.sql
                                endeksleri
                                   ... index.sql
                                tetikleyiciler
                                   ... trigger.sql

Uygulama daha sonra yeni yazılmış sürümü SVN'de saklanan sürümle karşılaştırır ve farklılıklar olması durumunda SVN'yi günceller. SQL'de bu kadar fazla değişiklik yapmadığımız için süreci bir kez çalıştırmanın yeterli olduğunu belirledik. Önem verdiğimiz tüm nesnelerdeki değişiklikleri izlememize ve ciddi bir sorun olması durumunda şemamızı yeniden oluşturmamıza olanak tanır.


Oooh, bu halka açık hale getirmek harika olurdu.
Chris Charabaruk

7

Bu uygulamayı bir süre önce yazdım, http://sqlschemasourcectrl.codeplex.com/ MSFT SQL db'nizi istediğiniz sıklıkta tarayacak ve nesnelerinizi (tablolar, görünümler, procs, işlevler, sql ayarları) SVN'ye otomatik olarak dökecek. Tıkır tıkır çalışıyor. Unfuddle ile kullanıyorum (bu da checkin'lerde uyarı almamı sağlıyor)


6

Tipik çözüm, gerektiğinde veritabanını dökmek ve bu dosyaları yedeklemek.

Geliştirme platformunuza bağlı olarak, açık kaynaklı eklentiler olabilir. Bunu yapmak için kendi kodunuzu yuvarlamak genellikle önemsizdir.

Not: Veritabanı dökümünü sürüm denetimine koymak yerine yedeklemek isteyebilirsiniz. Dosyalar sürüm kontrolünde çok hızlı olabilir ve tüm kaynak kontrol sisteminizin yavaşlamasına neden olabilir (Şu anda bir CVS korku hikayesini hatırlıyorum).


6

Team Foundation Server'ı kullanmaya başladık. Veritabanınız orta büyüklükteyse, visual studio yerleşik karşılaştırma, veri karşılaştırma, veritabanı yeniden düzenleme araçları, veritabanı test çerçevesi ve hatta veri oluşturma araçları ile bazı güzel proje entegrasyonlarına sahiptir.

Ancak, bu model çok büyük veya üçüncü taraf veritabanlarına (nesneleri şifreleyen) çok iyi uymuyor. Yani, yaptığımız sadece özelleştirilmiş nesnelerimizi saklamak. Visual Studio / Team vakıf sunucusu bunun için çok iyi çalışıyor.

TFS Veritabanı şefi. Blog

MS TFS sitesi


6

ESV yanıtıyla hemfikirim ve bu nedenle, veritabanı güncellemelerini çok basit bir dosyada korumak için bir süre önce küçük bir projeye başladım. Geliştiricilerin yanı sıra UAT ve Production için kolay güncellemeler sağlar. Araç Sql Server ve MySql üzerinde çalışıyor.

Bazı proje özellikleri:

  • Şema değişikliklerine izin verir
  • Değer ağacı popülasyonuna izin verir
  • Örneğin için ayrı test verisi eklerine izin verir. UAT
  • Geri alma seçeneğine izin verir (otomatik değil)
  • SQL sunucusu ve Mysql desteğini korur
  • Mevcut veritabanınızı basit bir komutla sürüm kontrolüne aktarabilir (yalnızca sql sunucusu ... hala mysql üzerinde çalışıyor)

Kod, google kodunda barındırılmaktadır. Daha fazla bilgi için lütfen Google koduna göz atın

http://code.google.com/p/databaseversioncontrol/


5

Bir süre önce, bir db'nin tamamını VSS'ye komut dosyası haline getirmek için DMO ve VSS nesnelerini kullanan bir VB bas modülü buldum. Bir VB Script'e çevirdim ve buraya gönderdim . Kolayca VSS çağrılarını çıkarabilir ve tüm komut dosyalarını oluşturmak için DMO şeylerini kullanabilir ve daha sonra bunları kontrol etmek için VBScript'i çağıran aynı toplu iş dosyasından SVN'yi çağırabilirsiniz?

Dave J


5

Ayrıca yordamlar veritabanı genişletilmiş özellikler ailesi aracılığıyla depolanan veritabanındaki bir sürümünü kullanıyorum. Uygulamamın her sürüm adımı için komut dosyaları var (yani 1.1'den 1.2'ye taşıyın). Konuşlandırıldığında, geçerli sürüme bakar ve komut dosyalarını son uygulama sürümüne ulaşıncaya kadar tek tek çalıştırır. Düz 'son' sürümü olan bir komut dosyası yoktur, temiz bir DB'de bile dağıtım bir dizi yükseltme adımıyla dağıtılır.

Eklemek istediğim, iki gün önce MS kampüsünde yeni ve yaklaşan VS DB sürümü hakkında bir sunum gördüm. Sunum özellikle bu konuya odaklanmıştı ve ben sudan atıldım. Kesinlikle kontrol etmelisiniz, yeni tesisler, dağıtım şemasını tanımlı şema ile karşılaştırmak ve delta ALTER'leri ve kaynak kodu entegrasyonu ile entegrasyonu yapmak için bir çalışma zamanı delta motoru olan T-SQL komut dosyalarında (CREATEs) şema tanımını tutmaya odaklanmıştır. ve otomatik yapım düşüşleri için MSBUILD sürekli entegrasyonunu içerir. Bırakma, dağıtım sitesine alınabilecek yeni bir dosya türü olan .dbschema dosyalarını içerecektir ve bir komut satırı aracı gerçek 'delta'ları yapabilir ve dağıtımı çalıştırabilir. Bu konuda VSDE indirmelerine bağlantılar içeren bir blog girişim var, bunları kontrol etmelisiniz:http://rusanu.com/2009/05/15/version-control-and-your-database/


5

Bu çok eski bir soru, ancak birçoğu bunu şimdi çözmeye çalışıyor. Tek yapmaları gereken Visual Studio Veritabanı Projeleri hakkında araştırma yapmak. Bu olmadan, herhangi bir veritabanı geliştirme çok zayıf görünüyor. Kod organizasyonundan konuşlandırmaya, sürümlemeye kadar her şeyi basitleştirir.


3

Deneyimlerime göre çözüm iki yönlüdür:

  1. Geliştirme sırasında birden çok geliştirici tarafından yapılan geliştirme veritabanındaki değişiklikleri işlemeniz gerekir.

  2. Müşteri sitelerinde veritabanı yükseltmelerini işlemeniz gerekir.

# 1 ile başa çıkmak için güçlü bir veritabanı fark / birleştirme aracına ihtiyacınız olacaktır. En iyi araç, ele alınmayan çakışmaları manuel olarak çözmenize izin verirken mümkün olduğunca otomatik birleştirme gerçekleştirebilmelidir.

Mükemmel araç, THEASES veritabanında ve MINE veritabanında yapılan değişiklikleri BASE veritabanına göre dikkate alan 3 yönlü birleştirme algoritması kullanarak birleştirme işlemlerini gerçekleştirmelidir.

SQLite veritabanları için manuel birleştirme desteği sağlayan ticari bir araç yazdım ve şu anda SQLite için 3 yollu birleştirme algoritması için destek ekliyorum. Şuraya göz atın:Http://www.sqlitecompare.com adresinden edin

# 2 ile başa çıkmak için yerinde bir yükseltme çerçevesine ihtiyacınız olacak.

Temel fikir, mevcut bir SQL şemasından daha yeni SQL şemasına nasıl yükseltileceğini bilen ve mevcut her DB kurulumu için bir yükseltme yolu oluşturabilen otomatik bir yükseltme çerçevesi geliştirmektir.

Konuyla ilgili makalemi http://www.codeproject.com/KB/database/sqlite_upgrade.aspx adresinde bulabilirsiniz.Ne hakkında konuştuğum hakkında genel bir fikir edinmek için .

İyi şanslar

Liron Levi


3

DBGhost http://www.innovartis.co.uk/ göz atın . 2 yıldır otomatik olarak kullandım ve harika çalışıyor. Veritabanılarımızın dışında, bir Java veya C derlemesi gibi DB derlemelerinin oluşmasına izin verir. Ne demek istediğimi biliyorsun.


2

Veritabanınız için bir sürüm kontrol sistemi doğaçlama yapmak için karşılaştırma araçlarını kullanmanızı öneririm. XSQL Şema Karşılaştırması ve xSQL Veri Karşılaştırması iyi bir alternatiftir .

Şimdi, hedefiniz yalnızca veritabanı şemasını sürüm kontrolü altında tutmaksa, şemanın xSQL Anlık Görüntülerini oluşturmak ve bu dosyaları sürüm kontrolünüze eklemek için xSQL Şema Karşılaştırması'nı kullanabilirsiniz. Daha sonra, belirli bir sürüme geri dönmek veya güncellemek için veritabanının geçerli sürümünü hedef sürümün anlık görüntüsü ile karşılaştırın.

Ne yazık ki, verilerin sürüm kontrolü altında olmasını istiyorsanız, veritabanınız için değişiklik komut dosyaları oluşturmak ve .sql dosyalarını sürüm kontrolünüze eklemek için xSQL Veri Karşılaştırması'nı kullanabilirsiniz. Daha sonra istediğiniz herhangi bir sürüme geri dönmek / güncellemek için bu komut dosyalarını yürütebilirsiniz. 'Geri döndür' işlevi için, yürütüldüğünde Sürüm 3'ü Sürüm 2 ile aynı hale getirecek değişiklik komut dosyaları oluşturmanız gerektiğini ve 'güncelleme' işlevselliği için bunun tersini yapan değişiklik komut dosyaları oluşturmanız gerektiğini unutmayın.

Son olarak, bazı temel toplu programlama becerileri ile xSQL Schema Compare ve xSQL Data Compare'in komut satırı sürümlerini kullanarak tüm süreci otomatikleştirebilirsiniz.

Feragatname: xSQL'e bağlıyım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.