Veritabanı öğeleriniz için kaynak denetimi kullanıyor musunuz? [kapalı]

Mağazamın bir deliği olduğunu hissediyorum çünkü veritabanı şeması değişikliklerini sürümlemek için sağlam bir süreç yok. Çok fazla yedek yapıyoruz, bu yüzden az çok kapalıyız, ancak bu şekilde son savunma hattınıza güvenmek kötü bir uygulamadır.

Şaşırtıcı bir şekilde, bu ortak bir konu gibi görünüyor. Bu sorunu görmezden gelmek için konuştuğum birçok dükkan, çünkü veritabanları sık sık değişmiyor ve temelde titiz olmaya çalışıyorlar.

Ancak, bu hikayenin nasıl geçtiğini biliyorum. İşlerin yanlış bir şekilde sıralanması ve bir şeylerin kaybolması sadece zaman meselesidir.

Bunun için en iyi uygulamalar var mı? İşinize yarayan bazı stratejiler nelerdir?

Okumalısınız Veritabanınızı sürüm kontrolü altına alın . K. Scott Allen'ın yayın dizisini kontrol edin.

Sürüm kontrolü söz konusu olduğunda, veritabanı genellikle ikinci hatta üçüncü sınıf bir vatandaştır. Gördüğüm kadarıyla, milyonlarca yıl boyunca sürüm kontrolü olmadan kod yazmayı düşünmeyecek takımlar - ve haklı olarak - bir şekilde, uygulamalarının güvendiği kritik veritabanlarının sürüm kontrolü ihtiyacından tamamen habersiz olabilirler. Veritabanınız kodunuzun geri kalanıyla tam olarak aynı titiz düzeyde denetim altında olmadığında, kendinize bir yazılım mühendisi diyebileceğiniz ve düz bir yüz koruyabileceğinizi bilmiyorum. Bunun olmasına izin verme. Veritabanınızı sürüm kontrolü altına alın.

Veritabanlarının kendileri mi? Hayır

Statik veri ekleri, saklı yordamlar ve benzerleri dahil, bunları oluşturan komut dosyaları; elbette. Metin dosyalarıdır, projeye dahil edilirler ve her şey gibi kontrol edilirler.

Tabii ideal bir dünyada veritabanı yönetim aracı bunu yapardı; ama sadece bu konuda disiplinli olmalısınız.

Rails ActiveRecord geçişlerini kesinlikle seviyorum. DML'yi yakut betiğe soyutlar ve bu da kaynak deponuzda kolayca sürümlendirilebilir.

Ancak, biraz çalışma ile aynı şeyi yapabilirsiniz. Herhangi bir DDL değişikliği (ALTER TABLE, vb.) Metin dosyalarında saklanabilir. Dosya adları için bir numaralandırma sistemi (veya tarih damgası) bulundurun ve bunları sırayla uygulayın.

Rails ayrıca DB'de son uygulanan geçişin kaydını tutan bir 'sürüm' tablosuna sahiptir. Aynı şeyi kolayca yapabilirsiniz.

Check out LiquiBase kaynak denetimi kullanarak veritabanı değişiklikleri yönetmek için.

Hiçbir zaman oturum açmamalı ve bir üretim veritabanını değiştirmek için "ALTER TABLE" komutlarını girmeye başlamamalısınız. Çalıştığım projenin her müşteri sitesinde veritabanı var ve bu nedenle veritabanındaki her değişiklik iki yerde, yeni bir müşteri sitesinde yeni bir veritabanı oluşturmak için kullanılan bir döküm dosyası ve çalıştırılan bir güncelleme dosyası mevcut veritabanı sürüm numaranızı dosyadaki en yüksek sayıya göre kontrol eden ve veritabanınızı güncelleyen her güncellemede. Örneğin, son birkaç güncelleme:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Eminim bunu yapmanın daha iyi bir yolu var, ama şu ana kadar benim için çalıştı.

Evet. Kod koddur. Temel kuralım , bir geliştirme veya üretim makinesine bakmadan uygulamayı sıfırdan oluşturabilmem ve kullanabilmem gerektiğidir .

Gördüğüm en iyi uygulama, veritabanınızı bir hazırlama sunucusunda kazımak ve yeniden oluşturmak için bir yapı komut dosyası oluşturmaktır. Her yinelemeye veritabanı değişiklikleri için bir klasör verildi, tüm değişiklikler "Bırak ... Oluştur" ile kodlandı. Bu şekilde, sürüm oluşturmak istediğiniz klasöre yönlendirerek istediğiniz zaman önceki bir sürüme geri dönebilirsiniz.

Bunun NaNt / CruiseControl ile yapıldığına inanıyorum.

EVET, veritabanınızı sürümlendirmenin önemli olduğunu düşünüyorum. Veriler değil, kesin şema.

Ruby On Rails'de bu, "taşıma" çerçevesiyle halledilir. Db'yi her değiştirdiğinizde, değişiklikleri uygulayan bir komut dosyası oluşturup kaynak denetimine denetlersiniz.

Mağazam bu fikri çok sevdi, çünkü kabuk komut dosyaları ve Ant kullanarak Java tabanlı derlememize işlevsellik ekledik . Süreci dağıtım rutinimize entegre ettik. Kutudan çıktığı haliyle DB sürümlemesini desteklemeyen diğer çerçevelerde aynı şeyi yapmak için komut dosyaları yazmak oldukça kolay olurdu.

Visual Studio'daki yeni Veritabanı projeleri, kaynak denetimi ve değişiklik komut dosyaları sağlar.

Veritabanlarını karşılaştıran ve birinin şemasını diğerine dönüştüren bir komut dosyası oluşturabilen veya birindeki verileri diğerine uyacak şekilde güncelleyen güzel bir araç var.

Db şeması, DB'yi tanımlayan her DDL komutu için bir tane olmak üzere çok sayıda küçük .sql dosyası oluşturmak üzere "parçalanır".

+ tom

Tamamlayıcı bilgiler 2008-11-30

Geçen yıl bir geliştirici olarak kullanıyorum ve gerçekten beğendim. Geliştirme işimi üretimle karşılaştırmayı ve sürüm için kullanılacak bir komut dosyası oluşturmayı kolaylaştırıyor. DBA'ların "kurumsal tip" projeler için ihtiyaç duyduğu özelliklerin eksik olup olmadığını bilmiyorum.

Şema sql dosyalarına "parçalanmış" olduğundan, kaynak denetimi iyi çalışır.

Bir gotcha, bir db projesi kullandığınızda farklı bir zihniyete sahip olmanız gerektiğidir. Aracın VS'de sadece sql olan bir "db projesi" ve şema ve diğer bazı yönetici verilerine sahip otomatik olarak oluşturulan bir yerel veritabanı vardır - ancak uygulama verilerinizin hiçbiri ve sizin için kullandığınız yerel geliştirici db'niz vardır. uygulama veri geliştirme çalışmaları. Otomatik olarak oluşturulan db'nin nadiren farkındasınız, ancak orada olduğunu bilmelisiniz, böylece yalnız bırakabilirsiniz :). Bu özel db açıkça tanınabilir, çünkü adında bir Rehber var,

VS DB Projesi, diğer ekip üyelerinin yerel projenize / ilişkili db'ye yaptıkları db değişikliklerini entegre etmek için iyi bir iş çıkarır. ancak proje şemasını yerel dev db şemanızla karşılaştırmak ve modları uygulamak için fazladan adım atmanız gerekir. Mantıklı, ama ilk başta garip görünüyor.

DB Projeleri çok güçlü bir araçtır. Yalnızca komut dosyası oluşturmakla kalmaz, aynı zamanda hemen uygulayabilirler. Üretim db onunla yok olmadığından emin olun. ;)

Ben gerçekten VS DB projeleri gibi ve ben ileride tüm db projeler için bu aracı kullanmayı bekliyoruz.

+ tom

Geliştirme ekiplerinin bir SQL veritabanı kaynak kontrol yönetim sistemi kullanmasını istemek, sorunların ortaya çıkmasını önleyecek sihirli mermi değildir. Veritabanı kaynak kontrolü, geliştiricilerin ayrı bir SQL komut dosyasında bir nesneye yaptıkları değişiklikleri kaydetmeleri, kaynak kontrol sistemi istemcisini açmaları, istemciyi kullanarak SQL komut dosyasını kontrol etmeleri ve daha sonra değişiklikleri canlı veritabanına uygular.

ApexSQL Source Control adlı SSMS eklentisini kullanmanızı önerebilirim . Geliştiricilerin doğrudan SSMS'den sihirbaz aracılığıyla kaynak nesnelerini veritabanı veritabanlarıyla kolayca eşlemelerini sağlar. Eklenti, TFS, Git, Subversion ve diğer SC sistemleri için destek içerir. Ayrıca, Statik verileri kontrol eden kaynak desteği de içerir.

ApexSQL Kaynak Kontrolü'nü indirip yükledikten sonra, sürüm kontrolü yapmak istediğiniz veritabanına sağ tıklayın ve SSMS'de ApexSQL Kaynak Kontrolü alt menüsüne gidin. Veritabanını kaynağa bağla seçeneğini tıklatın, kaynak kontrol sistemini ve geliştirme modelini seçin. Bundan sonra, seçtiğiniz kaynak kontrol sistemi için oturum açma bilgilerini ve depo dizesini sağlamanız gerekir.

Daha fazla bilgi için bu makaleyi okuyabilirsiniz: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Oluşturma / güncelleme komut dosyaları ve sampledata üreten bir komut dosyası kaydederek yapıyorum.

Evet, SQL'imizi yapımızın bir parçası olarak yapıyoruz - DROP.sql, CREATE.sql, USERS.sql, VALUES.sql ve sürüm bunları kontrol ediyor, böylece herhangi bir etiketli sürüme geri dönebiliriz.

Ayrıca gerektiğinde db'yi yeniden oluşturabilen karınca görevlerimiz var.

Ayrıca, SQL daha sonra kaynak kodunuzla birlikte etiketlenir.

Bir projede şimdiye kadar kullandığım en başarılı şema, yedekleri ve diferansiyel SQL dosyalarını birleştirdi. Temelde her sürümden sonra db'nin bir yedeğini alıp bir SQL dökümü yapacağız, böylece gerekirse sıfırdan boş bir şema oluşturabiliriz. Daha sonra DB'de değişiklik yapmanız gerektiğinde, sürüm denetimi altında sql dizinine bir alter komut dosyası eklersiniz. Her zaman dosya adına bir sıra numarası veya tarih önekini ekleriz, böylece ilk değişiklik 01_add_created_on_column.sql gibi olur ve sonraki komut dosyası 02_added_customers_index olur. CI makinemiz bunları kontrol eder ve yedeklemeden geri yüklenen db'nin yeni bir kopyasında sırayla çalıştırır.

Ayrıca, geliştiricilerin yerel db'lerini geçerli sürüme tek bir komutla yeniden başlatmak için kullanabileceği bazı komut dosyaları da vardı.

Tüm dabase tarafından oluşturulan nesneleri kaynak kontrolü yapıyoruz. Ve sadece geliştiricileri dürüst tutmak için (Kaynak Kontrolü olmadan nesneler oluşturabileceğiniz için), dbas'ımız periyodik olarak kaynak kontrolünde olmayan bir şey arar ve bir şey bulurlarsa, sorun olup olmadığını sormadan bırakırlar.

Ben tüm veritabanı şeması değişiklikleri sürüm kontrol SchemaBank kullanın:

• 1. günden itibaren, benim db şeması dökümü içine almak
• Bir web tarayıcısı kullanarak şema tasarımımı değiştirmeye başladım (çünkü SaaS / bulut tabanlı)
• benim db sunucumu güncellemek istediğinizde, ondan değişiklik (SQL) komut dosyası oluşturmak ve db için geçerlidir. Schemabank'ta, güncelleme betiği oluşturmadan önce çalışmamı bir sürüm olarak yürütmemi zorunlu kılıyorlar. Bu tür uygulamaları seviyorum, böylece ihtiyaç duyduğumda her zaman geri dönebiliyorum.

Takım kuralımız ASLA db sunucusuna doğrudan tasarım işini kaydetmeden dokunmayın. Ama olur, biri uygun olması için kuralı çiğnemeye cazip gelebilir. Şema dökümü tekrar şemabank içine aktarılır ve fark ve bir tutarsızlık bulunursa birini bash yapsın. Db ve şema tasarımımızı senkronize hale getirmek için ondan alter komut dosyaları oluşturabilsek de, bundan nefret ediyoruz.

Bu arada, sürüm kontrol ağacında dallar oluşturmamıza izin verdiler, böylece bir tane sahneleme ve diğeri üretim için koruyabilirim. Ve biri sandbox kodlamak için.

Sürüm kontrolü n değişiklik yönetimi ile oldukça temiz bir web tabanlı şema tasarım aracı.

DB'mi çıplak metalden yeniden oluşturmak için gerekli her şeye sahibim. Eminim bunu yapmak için birçok yol vardır, ancak tüm komut dosyaları ve bu tür yıkım kapalı saklanır ve biz tüm bu yıkılma dışarı çekerek ve bir yükleyici çalıştırarak DB yapısı ve böyle yeniden inşa edebilirsiniz.

Genelde yaptığım her değişiklik için bir SQL komut dosyası ve bu değişiklikleri geri almak için başka bir komut dosyası oluşturuyorum ve bu komut dosyalarını sürüm denetimi altında tutuyorum.

Daha sonra, talep üzerine yeni bir güncel veritabanı oluşturmak için bir aracımız var ve düzeltmeler arasında kolayca hareket edebiliriz. Her sürüm yaptığımızda, senaryoları bir araya getiriyoruz (biraz manuel çalışma alıyoruz, ancak nadiren zor ), bu yüzden sürümler arasında dönüştürülebilen bir dizi komut dosyasına da sahibiz.

Evet, söylemeden önce, bu Rails ve diğerlerinin yaptığı şeylere çok benziyor, ancak oldukça iyi çalışıyor gibi görünüyor, bu yüzden utanmadan fikrimi kaldırdığımı itiraf etmekte sorun yaşamıyorum :)

Ben MySQL Workbech dışa aktarılan SQL CREATE komut dosyaları kullanın, sonra onların "SQL ALTER İhracat" işlevselliğini kullanarak Ben bir dizi oluşturma komutları (elbette numaralı) ve aralarındaki değişiklikleri uygulayabilirsiniz değiştirmek komut dosyaları ile sonuçlanır.

3.- SQL ALTER betiğini dışa aktarma Normalde, modele yaptığınız değişiklikleri yansıtarak ALTER TABLE ifadelerini şimdi elinizle yazmanız gerekir. Ama akıllı olabilirsiniz ve Workbench'in zor işi sizin için yapmasına izin verin. Ana menüden Dosya -> Dışa Aktar -> İleri Mühendisi SQL ALTER Script… seçeneğini seçin.

Bu, geçerli modelin karşılaştırılması gereken SQL CREATE dosyasını belirtmenizi ister.

Adım 1'den SQL CREATE komut dosyasını seçin. Araç daha sonra sizin için ALTER TABLE komut dosyasını oluşturur ve bu komut dosyasını veritabanınıza karşı çalıştırarak güncel hale getirebilirsiniz.

Bunu MySQL Sorgu Tarayıcısını veya mysql istemcisini kullanarak yapabilirsiniz. Modeliniz ve veritabanınız şimdi senkronize edildi!

Kaynak: MySQL Workbench Topluluk Sürümü: Şema Senkronizasyonu Kılavuzu

Tüm bu scriptler elbette sürüm kontrolü altında.

Evet herzaman. Üretim veritabanı yapınızı, gerektiğinde yararlı bir örnek veri kümesiyle yeniden oluşturabilmeniz gerekir. Eğer yapmazsanız, zaman içinde işleri devam ettirmek için küçük değişiklikler unutulur, bir gün ısırılırsınız, büyük zaman. Eğer ihtiyacınız olduğunu düşünmüyor olabilir sigorta ama bunu gün 10 kat üzerinde fiyat değer!

Veritabanı modelinin kendisi hakkında çok fazla tartışma yapıldı, ancak gerekli verileri .SQL dosyalarında tutuyoruz.

Örneğin, kullanışlı olması için uygulamanızın kurulumda buna ihtiyacı olabilir:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

currency.sqlAlt sürüm olarak adlandırılan bir dosyamız olurdu . Derleme işleminde manuel bir adım olarak, önceki currency.sql dosyasını en sonuncuyla karşılaştırırız ve bir yükseltme komut dosyası yazarız.

Veritabanlarımızı çevreleyen her şeyi sürüm ve kaynak kontrol ediyoruz:

• DDL (oluşturma ve değiştirme)
• DML (referans verileri, kodlar vb.)
• Veri Modeli değişiklikleri (ERwin veya ER / Studio kullanarak)
• Veritabanı yapılandırma değişiklikleri (izinler, güvenlik nesneleri, genel yapılandırma değişiklikleri)

Tüm bunları Change Manager kullanan otomatik işlerle ve bazı özel komut dosyalarıyla yapıyoruz. Değişiklik Yöneticisi'ni bu değişiklikleri izliyor ve ne zaman yapıldığını bildiriyoruz.

Her DB'nin kaynak kontrolü altında olması gerektiğine ve geliştiricilerin yerel veritabanlarını sıfırdan oluşturmanın kolay bir yoluna sahip olması gerektiğine inanıyorum. Veritabanı Uzmanları için Visual Studio'dan esinlenerek, MS SQL veritabanlarını betikleyen ve bunları yerel DB motorunuza dağıtmanın kolay bir yolunu sağlayan açık kaynaklı bir araç oluşturdum. Http://dbsourcetools.codeplex.com/ adresini deneyin . İyi eğlenceler, - Nathan.

Veritabanınız SQL Server ise, sadece sizin aradığınız çözüme sahip olabiliriz. SQL Kaynak Denetimi 1.0 yayımlandı.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Bu SSMS ile bütünleşir ve veritabanı nesneleriniz ile VCS'niz arasında tutkal sağlar. 'Scripting out' şeffaf bir şekilde gerçekleşir (kaputun altındaki SQL Compare motorunu kullanır), bu da geliştiricilerin işlemi benimsemekten vazgeçirilmemesini kullanmayı çok basitleştirmelidir.

Alternatif bir Visual Studio çözümü, SSDT Veritabanı Projesi'nin alt türü olarak uygulanan ReadyRoll'dur . Bu, DevOps ekiplerinin otomasyon gereksinimlerine daha uygun olan, göç odaklı bir yaklaşım gerektirir.

Tüm nesneleri (tablo tanımları, dizinler, saklı yordamlar, vb.) Komut dosyası oluşturarak veritabanı şemasını kontrol kaynak. Ancak, verilerin kendisinde olduğu gibi, normal yedeklemelere güvenmeniz yeterlidir. Bu, tüm yapısal değişikliklerin uygun düzeltme geçmişiyle yakalanmasını sağlar, ancak veriler her değiştiğinde veritabanına yük getirmez.

İşimizde veritabanı değişiklik komut dosyaları kullanıyoruz. Bir komut dosyası çalıştırıldığında, adı veritabanında depolanır ve bu satır kaldırılmadığı sürece yeniden çalışmaz. Komut dosyaları tarih, saat ve kod dalına göre adlandırılır, bu nedenle kontrollü yürütme mümkündür.

Komut dosyaları canlı ortamda çalıştırılmadan önce çok sayıda test yapılır, bu nedenle "oopsiler" yalnızca genel olarak, geliştirme veritabanlarında gerçekleşir.

Tüm veritabanlarını kaynak kontrolüne taşıma sürecindeyiz. Veritabanını betimlemek için sqlcompare kullanıyoruz (maalesef bir meslek baskısı özelliği) ve bu sonucu SVN'ye koyuyoruz.

Uygulamanızın başarısı büyük ölçüde kuruluşunuzun kültürüne ve uygulamalarına bağlı olacaktır. Buradaki insanlar uygulama başına bir veritabanı oluşturmaya inanıyor. Çoğu uygulama tarafından kullanılan ve veritabanları arasında çok fazla bağımlılığa neden olan (bazıları daireseldir) yaygın bir veritabanı kümesi vardır. Sistemlerimizin sahip olduğu veritabanları arası bağımlılıklar nedeniyle veritabanı şemalarını kaynak denetimine sokmak çok zor olmuştur.

Size iyi şanslar, ne kadar çabuk denerseniz sorunlarınız o kadar çabuk çözülür.

Ben de THOUGHTWORKS gelen dbdeploy aracını kullandık http://dbdeploy.com/ . Geçiş komut dosyalarının kullanımını teşvik eder. Her sürümde, anlaşmayı kolaylaştırmak ve DBA'ların değişiklikleri 'kutsamalarına' izin vermek için değişiklik komut dosyalarını tek bir dosyada birleştirdik.

Bu benim için her zaman büyük bir sıkıntı oldu - geliştirme veritabanınızda hızlı bir değişiklik yapmak, kaydetmek (bir değişiklik komut dosyasını kaydetmeyi unutmak) çok kolay gibi görünüyor ve sonra sıkışıp kaldınız. Yaptığınız şeyi geri alabilir ve değişiklik komut dosyasını oluşturmak için yeniden yapabilirsiniz veya elbette isterseniz de sıfırdan yazabilirsiniz, ancak komut dosyaları yazmak için çok zaman harcanmıştır.

Geçmişte bu konuda yardımcı olan bir araç SQL Delta'dır. Size iki veritabanı (SQL sunucusu / Oracle inanıyorum) arasındaki farkları gösterecek ve A-> B'yi taşımak için gerekli tüm değişiklik komut dosyalarını oluşturacaktır. Yaptığı bir diğer güzel şey ise, üretim (veya test) DB'si ile geliştirme DB'niz arasındaki veritabanı içeriği arasındaki tüm farklılıkları göstermektir. Giderek daha fazla uygulama, veritabanı tablolarında yürütülmesi için çok önemli olan yapılandırmayı ve durumu depoladığından, uygun satırları kaldıran, ekleyen ve değiştiren değişiklik komut dosyalarına sahip olmak gerçek bir acı olabilir. SQL Delta, veritabanındaki satırları tıpkı bir Diff aracında göründüğü gibi gösterir - değiştirildi, eklendi, silindi.

Mükemmel bir araç. Bağlantı: http://www.sqldelta.com/

RedGate harika, veritabanı değişiklikleri yapıldığında (küçük bir ikili dosya) yeni anlık görüntüler oluşturuyoruz ve bu dosyayı projelerde kaynak olarak tutuyoruz. Veritabanını güncellememiz gerektiğinde, veritabanını güncellemek ve boş veri tabanlarından yeni veritabanları oluşturmak için RedGate'in araç setini kullanırız.

RedGate ayrıca Veri anlık görüntüleri yapar, ben onlarla kişisel olarak çalışmamış olsam da, onlar kadar sağlamdır.

FYI Bu da birkaç gün önce Dana tarafından gündeme getirildi ... Kayıtlı prosedürler / kaynak kontrolünde DB şeması