DB şema değişikliklerini izleme mekanizmaları [kapalı]


135

DB şema değişikliklerini izlemek ve / veya otomatikleştirmek için en iyi yöntemler nelerdir? Ekibimiz sürüm kontrolü için Subversion kullanıyor ve bazı görevlerimizi bu şekilde otomatikleştirebildik (derlemeleri bir hazırlama sunucusuna göndermek, test edilmiş kodu bir üretim sunucusuna dağıtmak) ancak yine de veritabanı güncellemelerini manuel olarak yapıyoruz. Subversion'u kod ve DB güncellemelerinin çeşitli sunuculara aktarıldığı bir arka uç olarak kullanmaya devam ederken, farklı ortamlara sahip sunucular arasında verimli bir şekilde çalışmamızı sağlayan bir çözüm bulmak veya oluşturmak istiyorum.

Birçok popüler yazılım paketi, DB sürümünü algılayan ve gerekli değişiklikleri uygulayan otomatik güncelleme komut dosyaları içerir. Bunu daha büyük ölçekte bile yapmanın en iyi yolu (birden fazla proje ve bazen birden fazla ortam ve dil arasında) mı? Eğer öyleyse, süreci basitleştiren mevcut bir kod var mı yoksa sadece kendi çözümümüzü yuvarlamak en iyisi mi? Herkes daha önce benzer bir şey uyguladı ve Subversion taahhüt sonrası kancalara entegre etti mi, yoksa bu kötü bir fikir mi?

Birden fazla platformu destekleyen bir çözüm tercih edilebilir olsa da, çalışmalarımızın çoğunluğu bu platformda olduğu için kesinlikle Linux / Apache / MySQL / PHP yığınını desteklememiz gerekir.

Yanıtlar:


56

Rails dünyasında, veritabanında özel bir SQL lezzeti yerine, veritabanında değişikliklerin Ruby'de yapıldığı geçişler, komut dosyaları kavramı vardır. Ruby geçiş kodunuz, geçerli veritabanınıza özgü DDL'ye dönüştürülür; bu veritabanı platformlarını değiştirmeyi çok kolaylaştırır.

Veritabanında yaptığınız her değişiklik için yeni bir taşıma yazarsınız. Taşıma işlemlerinin genellikle iki yöntemi vardır: değişikliklerin uygulandığı bir "yukarı" yöntemi ve değişikliklerin geri alındığı "aşağı" yöntemi. Tek bir komut, veritabanını güncel hale getirir ve veritabanını şemanın belirli bir sürümüne getirmek için de kullanılabilir. Rails'te taşıma işlemleri proje dizinindeki kendi dizininde tutulur ve diğer tüm proje kodlarında olduğu gibi sürüm kontrolüne alınır.

Bu Rails taşıma kılavuzları , taşıma işlemlerini oldukça iyi bir şekilde kapsamaktadır.

Diğer dilleri kullanan geliştiriciler taşıma işlemlerine baktılar ve kendi dile özgü sürümlerini uyguladılar. Rails 'göçlerinden sonra modellenen bir PHP göç sistemi olan Ruckusing'i biliyorum ; aradığınız şey olabilir.


1
Ruckusing FTW - db sistemimize uyarladık ve oldukça mutluyuz.
Piskvor binadan

Şimdi github'da

50

Veritabanı şemamızı 5 farklı kurulumda (üretim, aşamalandırma ve birkaç geliştirme kurulumu) senkronize tutmak ve sürüm kontrolünde yedeklemek için bcwoord'a benzer bir şey kullanırız ve oldukça iyi çalışır. Biraz detaylandıracağım:


Veritabanı yapısını senkronize etmek için tek bir script, update.php ve 1.sql, 2.sql, 3.sql, vb. Olarak adlandırılan bir takım dosyalarımız vardır. Komut dosyası, veri tabanı. N.sql dosyaları, sürüm (N-1) 'den veritabanının N sürümüne gitmek için el ile hazırlanmıştır.

Tablo eklemek, sütun eklemek, eskiden yeni bir sütun biçimine veri taşımak, sonra sütunu bırakmak, kullanıcı türleri gibi "ana" veri satırlarını eklemek için kullanılabilir. Temel olarak, her şeyi yapabilir ve uygun verilerle taşıma komut dosyaları asla veri kaybetmezsiniz.

Güncelleme komut dosyası şu şekilde çalışır:

  • Veritabanına bağlanın.
  • Geçerli veritabanında (malzeme nedeniyle bir yedeğini alın edecek yanlış) [Mysqldump].
  • Yoksa, defter tutma tablosu (_meta olarak adlandırılır) oluşturun.
  • Geçerli VERSION sürümünü _meta tablosundan okuyun. Bulunmazsa 0 olduğunu varsayın.
  • VERSION değerinden daha yüksek numaralı tüm .sql dosyaları için bunları sırayla yürütün
  • Dosyalardan biri hata ürettiyse: yedeklemeye geri dönün
  • Aksi takdirde, defter tutma tablosundaki sürümü yürütülen en yüksek .sql dosyasına güncelleyin.

Her şey kaynak kontrolüne girer ve her kurulum tek bir komut dosyası yürütmesiyle en son sürüme güncellenecek bir komut dosyasına sahiptir (uygun veritabanı şifresi ile update.php çağrılır). Hazırlama ve üretim ortamlarını, veritabanı güncelleme komut dosyasını otomatik olarak çağıran bir komut dosyası aracılığıyla güncelleştiririz, böylece gerekli veritabanı güncelleştirmeleriyle birlikte bir kod güncelleştirmesi gelir.

Tüm veritabanını sıfırdan yeniden oluşturmak için aynı komut dosyasını da kullanabiliriz; veritabanını bırakıp yeniden oluşturduktan sonra veritabanını tamamen yeniden dolduracak komut dosyasını çalıştırıyoruz. Komut dosyasını, otomatik sınama için boş bir veritabanı doldurmak için de kullanabiliriz.


Bu sistemi kurmak sadece birkaç saat sürdü, kavramsal olarak basit ve herkes sürüm numaralandırma şemasını aldı ve değişiklikleri iletmek veya manuel olarak yürütmek zorunda kalmadan, veritabanı tasarımını ileriye taşıma ve geliştirme yeteneğine sahip olmak çok değerli oldu. tüm veritabanlarında.

Yine de phpMyAdmin sorguları yapıştırırken sakının! Bu oluşturulan sorgular genellikle komut dosyalarınızı kıracağından kesinlikle istemediğiniz veritabanı adını içerir! TABLO OLUŞTUR gibi bir şey mydb. newtable(...) sistemdeki veritabanı mydb olarak adlandırılmazsa başarısız olur. Dizeyi içeren .sql dosyalarına izin vermeyecek bir yorum öncesi SVN kancası oluşturduk mydb;


Çarpışmalarla nasıl başa çıktınız? Birden çok geliştirici DB aynı öğeyi değiştirerek, örneğin bir saklı yordam? Bu, aynı dalda aynı anda çalışıyorsanız veya iki geliştirme hattınız varsa (iki dal) olabilir
Asaf Mesika

Çarpışmalar çok nadirdi; gerçekte olan tek şey, iki kişinin aynı N.sql dosyasını oluşturmaya çalışmasıdır. Tabii ki, birincisi kazanır ve ikincisi bir sonraki en yüksek sayıya yeniden adlandırmak ve tekrar denemek zorunda kalır. Yine de bir dalda veritabanı sürümümüz yoktu.
10:34

12

Ekibim tüm veritabanı değişikliklerini betimler ve uygulamanın her sürümü ile birlikte bu betikleri SVN'ye verir. Bu, herhangi bir veri kaybetmeden veritabanının artımlı olarak değiştirilmesine izin verir.

Bir sürümden diğerine geçmek için, değişiklik komut dosyaları kümesini çalıştırmanız yeterlidir ve veritabanınız günceldir ve yine de tüm verilerinize sahipsiniz. En kolay yöntem olmayabilir, ancak kesinlikle etkilidir.


1
tüm değişiklikleri nasıl yazarsınız?
Smith

10

Buradaki sorun, geliştiricilerin kendi yerel değişikliklerini ekiple paylaşmak üzere kaynak kontrolüne yazmasını gerçekten kolaylaştırıyor. Uzun yıllardır bu sorunla karşı karşıya kaldım ve Visual Studio for Database uzmanlarının işlevselliğinden ilham aldım. Aynı özelliklere sahip açık kaynaklı bir araç istiyorsanız şunu deneyin: http://dbsourcetools.codeplex.com/ İyi eğlenceler, - Nathan.


10

Hala çözüm arıyorsanız: neXtep tasarımcısı adlı bir araç öneriyoruz. Tüm veritabanınızı sürüm kontrolü altına alabileceğiniz bir veritabanı geliştirme ortamıdır. Her değişikliğin izlenebileceği sürüm kontrollü bir depo üzerinde çalışıyorsunuz.

Bir güncelleştirme yayınlamanız gerektiğinde, bileşenlerinizi uygulayabilirsiniz ve ürün otomatik olarak önceki sürümden SQL yükseltme komut dosyasını oluşturur. Tabii ki, bu SQL herhangi bir 2 sürümden oluşturabilirsiniz.

Sonra birçok seçeneğiniz var: bu komut dosyalarını alıp uygulama kodunuzla SVN'nize koyabilirsiniz, böylece mevcut mekanizmanız tarafından dağıtılacaktır. Başka bir seçenek neXtep'in dağıtım mekanizmasını kullanmaktır: komut dosyaları "dağıtım paketi" (SQL komut dosyaları + XML tanımlayıcı) olarak adlandırılan bir şeye aktarılır ve bir yükleyici bu paketi anlayabilir ve strustural tutarlılık, bağımlılık sağlarken bir hedef sunucuya dağıtabilir kontrol edin, kurulu sürümü kaydetme vb.

Ürün GPL'dir ve Eclipse tabanlıdır, bu yüzden Linux, Mac ve pencerelerde çalışır. Ayrıca şu anda Oracle, Mysql ve Postgresql'i de destekliyor (DB2 desteği yolda). Daha ayrıntılı bilgi bulabileceğiniz wiki'ye bir göz atın: http://www.nextep-softwares.com/wiki


İlgi çekici görünüyor. Komut satırı arabirimi de var mı, yoksa planlı mı?
Piskvor binadan

8

Scott Ambler, şemanızı korumak için temel olarak TDD ilke ve uygulamalarını uygulamanız gerektiği düşüncesiyle, veritabanı yeniden düzenleme üzerine çok sayıda makale (ve bir kitap birlikte yazdı ) üretir . Veritabanı için bir dizi yapı ve tohum veri birimi testleri oluşturdunuz. Daha sonra, herhangi bir şeyi değiştirmeden önce, bu değişikliği yansıtacak şekilde testleri değiştirir / yazarsınız.

Bunu bir süredir yapıyoruz ve işe yarıyor gibi görünüyor. Birim test paketinde temel sütun adı ve veri türü kontrolleri oluşturmak için kod yazdık. SVN kasasındaki veritabanının uygulamanın çalışmakta olduğu canlı db ile eşleştiğini doğrulamak için her zaman bu testleri tekrar çalıştırabiliriz.

Görünüşe göre, geliştiriciler bazen sanal alan veritabanını değiştiriyor ve SVN'deki şema dosyasını güncellemeyi ihmal ediyorlar. Kod daha sonra kontrol edilmemiş bir db değişikliğine bağlıdır. Bu tür bir hata çıldırtıcı bir şekilde sabitlemek zor olabilir, ancak test paketi hemen alacaktır. Bu, daha geniş bir Sürekli Entegrasyon planında yerleşik olarak bulunması özellikle güzeldir.


7

Şemanızı bir dosyaya dökün ve kaynak denetimine ekleyin. Sonra basit bir fark neyin değiştiğini gösterecektir.


1
Döküm bir SQL gibi olmalıdır, mysqldump gibi, Oracle'ın dökümleri ikili.
Osama Al-Maadeed

7
Ayrıca şemanın farklılaşmasında daha temel bir sorun vardır. Bir sütun bırakma + ekleme işlemini bir sütun yeniden adlandırma yönteminden nasıl ayırt edersiniz? Cevap basit: Yapamazsınız. Gerçek şema değişikliği işlemlerini kaydetmeniz için bu nedenle gereklidir.
psp

Fark, bir sütunun gittiğini, diğerinin göründüğünü (aynı ada sahip olmadıkları sürece) ve çoğu zaman yeterli olduğunu gösterir. Her şema değişikliğini kodlamak elbette iyi bir yoldur: Drupal'da bu örneğin özel bir kanca ile ele alınır.
deadprogrammer


5

Bu biraz düşük bir teknolojidir ve daha iyi bir çözüm olabilir, ancak şemanızı veritabanını oluşturmak için çalıştırılabilecek bir SQL komut dosyasında saklayabilirsiniz. Bu komut dosyasını oluşturmak için bir komut yürütebilirsiniz düşünüyorum, ama ne yazık ki komutu bilmiyorum.

Ardından, komut dosyasını üzerinde çalışan kodla birlikte kaynak denetimine alın. Şemayı kodla birlikte değiştirmeniz gerektiğinde, komut dosyası, değiştirilen şemayı gerektiren kodla birlikte teslim edilebilir. Ardından, komut dosyasındaki farklar şema değişikliklerindeki farkları gösterecektir.

Bu komut dosyasıyla, DBUnit veya bir tür oluşturma komut dosyası ile entegre edebilirsiniz, bu yüzden zaten otomatikleştirilmiş işlemlerinize sığabileceği anlaşılıyor.


Evet, şu anda yerinde olan şey bu. Ne yazık ki bu bize mevcut veritabanlarını değiştirmenin kolay bir yolunu vermiyor - mysqldump tarafından oluşturulan SQL komut dosyası, tabloyu sıfırdan oluşturduğunuzu (veya varsa bir tablonun üzerine yazdığınızı). Biraz daha ileri teknolojiye ihtiyacımız var, çünkü veritabanına bir dizi ALTER TABLE ifadesi uygulamak gerekiyor ve bunu doğru bir şekilde yapabilmek için veritabanının mevcut durumunun farkında olması gerekiyor.
pix0r

5

C # kullanıyorsanız, çok kullanışlı bir ORM aracı olan Subsonic'e bir göz atın, ancak şemanızı ve \ veya verilerinizi yeniden oluşturmak için sql komut dosyası oluşturur. Bu komut dosyaları daha sonra kaynak denetimine alınabilir.

http://subsonicproject.com/


Bu noktadan itibaren ölü bir URL gibi görünüyor.
Mark Schultheiss

5

Visual Studio'da birkaç proje için aşağıdaki veritabanı proje yapısını kullandım ve oldukça iyi çalıştı:

Veri tabanı

Komut Dosyalarını Değiştir

0.PreDeploy.sql

1.SchemaChanges.sql

2.DataChanges.sql

3.Permissions.sql

Komut Dosyaları Oluşturun

SPROCs

Fonksiyonlar

Görüntüleme

Derleme sistemimiz daha sonra komut dosyalarını aşağıdaki sırada çalıştırarak veritabanını bir sürümden diğerine günceller:

1.PreDeploy.sql

2.SchemaChanges.sql

Komut Dosyaları Oluştur klasörünün içeriği

2.DataChanges.sql

3.Permissions.sql

Her geliştirici, kodlarını her dosyanın sonuna ekleyerek belirli bir hata / özellik için değişikliklerini kontrol eder. Ana sürüm tamamlandığında ve kaynak denetiminde dallandığında, Komut Dosyalarını Değiştir klasöründeki .sql dosyalarının içeriği silinir.


5

Çok basit ama etkili bir çözüm kullanıyoruz.

Yeni yüklemeler için, depoda tüm DB şemasını barındıran bir metadata.sql dosyası var, daha sonra oluşturma işleminde veritabanını oluşturmak için bu dosyayı kullanıyoruz.

Güncellemeler için, yazılım sabit kodlu güncellemeleri ekleriz. Sabit kodlu tutuyoruz çünkü gerçekten bir sorun OLMADAN problem çözmeyi sevmiyoruz ve bu tür bir şey şimdiye kadar bir problem olduğunu kanıtlamadı.

Yani yazılımımızda böyle bir şey var:

RegisterUpgrade(1, 'ALTER TABLE XX ADD XY CHAR(1) NOT NULL;');

Bu kod, veritabanının sürüm 1'de olup olmadığını (otomatik olarak oluşturulan bir tabloda depolanır), eskiyse, komut yürütülür.

Depodaki metadata.sql dosyasını güncelleştirmek için, bu yükseltmeleri yerel olarak çalıştırır ve sonra tam veritabanı meta verilerini çıkarırız.

Sık sık gerçekleşen tek şey, metadata.sql dosyasını çalıştırmayı unutmaktır, ancak bu büyük bir sorun değildir, çünkü derleme sürecini test etmek kolaydır ve ayrıca olabilecek tek şey yeni bir kurulum yapmaktır. eski bir veritabanı ve ilk kullanımda yükseltti.

Ayrıca sürüm düşürmeleri desteklemiyoruz, ancak tasarım gereği, bir güncellemede bir şey kırılırsa, önceki sürümü geri yükledik ve tekrar denemeden önce güncellemeyi düzelttik.


4

Derleme sürümlerinden sonra klasörler oluşturur ve yükseltme ve düşürme komut dosyalarını oraya koyarım. Örneğin, aşağıdaki klasörlere sahip olabilirsiniz: 1.0.0, 1.0.1 ve 1.0.2. Her biri, veritabanınızı sürümler arasında yükseltmenizi veya düşürmenizi sağlayan komut dosyasını içerir.

Bir müşteri veya müşteri 1.0.1 sürümü ile ilgili bir sorunla sizi ararsa ve 1.0.2'yi kullanıyorsanız, veritabanını sürümüne geri getirmek sorun olmayacaktır.

Veritabanınızda, veritabanının geçerli sürümüne koyduğunuz "şema" adlı bir tablo oluşturun. Daha sonra veritabanınızı sizin için yükseltebilecek veya düşürebilecek bir program yazmak kolaydır.

Joey'nin söylediği gibi, Rails dünyasındaysanız Göçleri kullanın. :)


3

Şu anki PHP projem için ray geçişi fikrini kullanıyoruz ve "migration_XX.sql" başlıklı dosyaları sakladığımız bir geçiş dizinimiz var, burada XX geçiş sayısıdır. Şu anda bu dosyalar, güncellemeler yapıldıkça elle oluşturulmaktadır, ancak bunların oluşturulması kolayca değiştirilebilir.

Ardından, "alfa öncesi" olarak, şu anda her sayfa yüklemesinde çalışan ve XX'nin geçerli taşıma sürümünden daha büyük olduğu yeni bir migration_XX.sql dosyasının olup olmadığını kontrol eden "Migration_watcher" adlı bir komut dosyamız var. Bu durumda, tüm migration_XX.sql dosyalarını veritabanı ve voila'ya karşı en büyük sayıya kadar çalıştırır! şema değişiklikleri otomatiktir.

Sistemi geri alma yeteneğine ihtiyacınız varsa, çok fazla ayar gerektirecektir, ancak basit ve şu ana kadar oldukça küçük ekibimiz için çok iyi çalışıyor.


3

"Komut dosyası" tarafı için Ant (çapraz platform) (pratikte orada jdbc aracılığıyla herhangi bir db ile konuşabilirsiniz çünkü) ve Subversion kaynak depo için kullanmanızı tavsiye ederim. Ant değişiklik yapmadan önce db'nizi yerel dosyalara "yedeklemenizi" sağlayacaktır. 1. Ant ile dosyaya mevcut db şemasını yedekleme 2. Ant ile Subversion veri havuzuna sürüm kontrolü 3. Ant ile db yeni sql ifadeleri göndermek


3

MySQL için Toad, 2 veritabanını senkronize etmenizi sağlayan şema karşılaştırması adlı bir işleve sahiptir. Şimdiye kadar kullandığım en iyi araç.


3

Yii'nin veritabanı geçişlerini nasıl ele aldığını seviyorum . Taşıma temelde bir PHP betiği uygulamasıdır CDbMigration. geçiş mantığını içeren CDbMigrationbir upyöntemi tanımlar . downGöçün tersine çevrilmesini desteklemek için bir yöntem uygulamak da mümkündür . Alternatif olarak, safeUpveya safeDowntaşıma işleminin işlem bağlamında yapıldığından emin olmak için kullanılabilir.

Yii'nin komut satırı aracı yiic, taşıma oluşturma ve yürütme desteği içerir. Taşıma işlemleri tek tek veya toplu olarak uygulanabilir veya tersine çevrilebilir. Geçiş oluşturmak CDbMigration, bir zaman damgasına ve kullanıcı tarafından belirtilen bir geçiş adına dayalı olarak benzersiz bir şekilde adlandırılan bir PHP sınıfı uygulaması için kodla sonuçlanır . Daha önce veritabanına uygulanan tüm geçişler bir geçiş tablosunda depolanır.

Daha fazla bilgi için kılavuzdaki Veritabanı Geçişi makalesine bakın.



2

IMHO taşımalarının büyük bir sorunu var:

Bir sürümden diğerine yükseltme iyi çalışır, ancak yüzlerce tablonuz ve uzun bir değişiklik geçmişiniz varsa (yaptığımız gibi) belirli bir sürümün yeni bir yüklemesini yapmak sonsuza kadar sürebilir.

Mevcut sürüme kadar (yüzlerce müşteri veritabanı için) başlangıçtan bu yana tüm delta geçmişini çalıştırmak çok uzun zaman alabilir.


0

Veritabanı şemalarını karşılaştıran bir komut satırı mysql-diff aracı vardır, burada şema diskte canlı bir veritabanı veya SQL komut dosyası olabilir. Çoğu şema taşıma görevi için iyidir.

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.