Veritabanı şemanızı nasıl versiyonlarsınız? [kapalı]

SQL deltalarınızı nasıl hazırlıyorsunuz? her şema değiştiren SQL'i manuel olarak bir delta klasörüne mi kaydediyorsunuz yoksa otomatikleştirilmiş bir farklılaştırma süreciniz mi var?

Kaynak kodu ile birlikte veritabanı şemasını versiyonlama kurallarıyla ilgileniyorum. Belki de şemayı farklılaştıran bir ön işleme kancası?

Ayrıca, deltalar diffing için hangi seçeneklerin kenara var DbDeploy ?

DÜZENLEME: cevapları görünce, deltalar kullanarak bir veritabanı geçişi çalıştırmak için standart şemaya aşina olduğumu açıklığa kavuşturmak isterim. Sorum, deltaların kendilerinin, tercihen otomatik olarak oluşturulmasıyla ilgili.

Ayrıca, bir fark yaratıyorsa, sürüm oluşturma PHP ve MySQL içindir. (Lütfen Ruby çözümleri kullanmayın).

Görmek

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

MS SQL veritabanımı SVN'de nasıl versiyonlayabilirim?

ve Jeff'in makalesi

Veritabanınızı Sürüm Kontrolü Altına Alın

Acını hissediyorum ve keşke daha iyi bir cevap olsaydı. Bu aradığınız şeye daha yakın olabilir.

DB şema değişikliklerini izleme mekanizmaları

Genel olarak, buna yeterli ve kabul edilmiş bir çözüm olmadığını hissediyorum ve bu alanda kendimi yuvarlıyorum.

Başka bir benzer iş parçacığına bakabilirsiniz: MS SQL veritabanımı SVN'de nasıl biçimlendirebilirim? .

Hala seçenek arıyorsanız: neXtep tasarımcısına bir göz atın. Sürüm kontrolü kavramlarına dayanan ücretsiz bir GPL veritabanı geliştirme ortamıdır. Ortamda her zaman versiyonlu varlıklarla çalışırsınız ve veri modeli geliştirmeye odaklanabilirsiniz. Bir sürüm tamamlandığında, sürüm kontrol sistemine takılan SQL nesil motoru, 2 sürüm arasında ihtiyacınız olan herhangi bir deltayı oluşturabilir ve ihtiyacınız olursa size bazı teslim mekanizmaları sunacaktır.

Diğer şeylerin yanı sıra, geliştirmeler sırasında veritabanınızı senkronize edebilir ve tersine senkronize edebilir, veri modeli diyagramları oluşturabilir, entegre SQL istemcileri kullanarak veritabanınızı sorgulayabilirsiniz, vb.

Daha fazla bilgi için wiki'ye bakın: http://www.nextep-softwares.com/wiki

Şu anda Oracle, MySql ve PostgreSql'i destekliyor ve java'da olduğu için ürün windows, linux ve mac üzerinde çalışıyor.

Şema değişikliklerinin her zaman eklemeli olduğundan emin oluyorum. Bu yüzden sütunları ve tabloları düşürmüyorum, çünkü bu veriler zap olur ve daha sonra geri alınamaz. Bu şekilde, veritabanını kullanan kod, veri veya işlevsellik kaybı olmadan geri alınabilir.

Henüz yoksa tablolar ve sütunlar oluşturan ve bunları verilerle dolduran ifadeler içeren bir geçiş betiğim var.

Taşıma betiği, üretim kodu her güncellendiğinde ve yeni kurulumlardan sonra çalışır.

Bir şeyi bırakmak istediğimde, bunları veritabanı yükleme betiğinden ve geçiş betiğinden kaldırarak yapıyorum, böylece bu eski şema öğeleri yeni yüklemelerde aşamalı olarak kaldırılacak. Yeni yüklemelerin yüklemeden önce eski bir sürüme indirilememesi dezavantajıdır.

Ve elbette DDL'leri bu komut dosyaları aracılığıyla çalıştırıyorum ve hiçbir zaman doğrudan veri tabanında değil, işleri senkronize tutmak için.

Deltaları yönetmiyorum. Bir ana veritabanında değişiklikler yapıyorum ve ana veritabanına dayalı XML tabanlı bir yapı betiği oluşturan bir araca sahibim.

Mevcut bir veritabanını yükseltme zamanı geldiğinde, yeni bir veritabanı ve çıplak tablolar oluşturmak için XML tabanlı oluşturma komut dosyasını kullanan bir programım var. Daha sonra INSERT INTO x SELECT FROM y kullanarak verileri eski veritabanından kopyalıyorum ve sonra tüm indeksleri, kısıtlamaları ve tetikleyicileri uyguluyorum.

Yeni tablolar, yeni sütunlar, silinmiş sütunların tümü otomatik olarak işlenir ve kopyalama rutinini ayarlamak için birkaç küçük hile ile sütun yeniden adlarını, sütun türü değişikliklerini ve diğer temel yeniden düzenlemeleri yapabilirim.

Bu çözümü büyük miktarda veriye sahip bir veri tabanında önermem ama 400 tablo ile 1GB üzerindeki bir veri tabanını düzenli olarak güncelliyorum.

Hangi RDBMS'yi kullandığınızı söylemediniz, ancak MS SQL Sunucusuysa, Red-Gate'in SQL Karşılaştırması , nesne oluşturma komut dosyaları arasında delta oluşturmada bizim için vazgeçilmez olmuştur.

Kendi başıma konuşacak biri değilim, ancak veritabanı şemalarındaki değişiklikleri izlemek ve sürümü belirlenmiş güncelleme komut dosyaları oluşturmak için dahili bir web uygulaması geliştirdim.

Bu aracın adı Brezilya'dır ve artık MIT lisansı altında açık kaynaklıdır. Brezilya, ray tabanlı Ruby / Ruby'dir ve Ruby DBI'nin desteklediği herhangi bir veritabanına (MySQL, ODBC, Oracle, Postgres, SQLite) değişiklik dağıtımını destekler.

Güncelleme komut dosyalarının sürüm kontrolüne alınması için destek planlanmıştır.

http://bitbucket.org/idler/mmp - PHP'de yazılmış mysql için şema sürüm belirleme aracı

Verileri taşınabilir bir biçime aktarıyoruz (araç zincirimizi kullanarak), ardından yeni bir şemaya aktarıyoruz. delta SQL'e gerek yok. Şiddetle tavsiye edilir.

Çoğu geliştirme için Firebird veritabanını kullanıyorum ve bunun için FlameRobin yönetim aracını kullanıyorum . Tüm değişiklikleri günlüğe kaydetme seçeneği vardır. Her şeyi tek bir büyük dosyaya veya veritabanı değişikliği başına bir dosyaya kaydedebilir. Bu ikinci seçeneği kullanıyorum ve ardından her komut dosyasını sürüm kontrol yazılımında depoluyorum - daha önce Subversion kullanıyordum, şimdi Git kullanıyorum.

FlameRobin'in Firebird için yaptığı gibi aynı günlüğe kaydetme özelliğine sahip bazı MySQL aracı bulabileceğinizi varsayıyorum.

Veritabanı tablolarından birinde veritabanı yapısının sürüm numarasını saklıyorum, böylece herhangi bir veritabanını kolayca yükseltebilirim. Ayrıca bu SQL betiklerini herhangi bir hedef veritabanında tek tek çalıştıran basit bir PHP betiği yazdım (veritabanı yolu ve kullanıcı adı / şifre komut satırında sağlanır).

Ayrıca tüm DML (ekle, güncelle silme) ifadelerini günlüğe kaydetme seçeneği var ve her veritabanının içerdiği bazı 'varsayılan' verileri değiştirirken bunu etkinleştiriyorum.

Tüm bunları nasıl yaptığımı ayrıntılı olarak anlatan güzel bir beyaz kağıt yazdım. Sen den demo php el yazılarıyla birlikte .pdf formatında kağıt indirebilirsiniz burada .

Ayrıca geliştiricilerin deltasql betiklerini merkezi bir depoya gönderebilecekleri bir dizi PHP betiği geliştirdim.

Veritabanı tablolarından birinde (TBSYNCHRONIZE olarak adlandırılır), en son çalıştırılan betiğin sürüm numarasını saklıyorum, böylece web arayüzü veya Eclipse için özel olarak geliştirilmiş bir istemci kullanarak herhangi bir veritabanını kolayca yükseltebilirim.

Web arayüzü birkaç projeyi yönetmeye izin verir. Ayrıca veritabanı "dallarını" da destekler.

Uygulamayı http://www.gpu-grid.net/deltasql adresinde test edebilirsiniz (şifre testidbsync ile yönetici olarak oturum açarsanız). Uygulama açık kaynak kodludur ve buradan indirilebilir: http://sourceforge.net/projects/deltasql

deltasql, İsviçre ve Hindistan'da verimli bir şekilde kullanılır ve Japonya'da popülerdir.

Birkaç ay önce MySQL şemasını versiyonlamak için bir araç aradım. Doctrine geçişi, RoR geçişi, Java ve Python ile yazılmış bazı araçlar gibi birçok yararlı araç buldum.

Ama hiçbiri benim gereksinimlerimi karşılamadı.

Gereksinimlerim:

1. Gereksinim yok, PHP ve MySQL'i hariç tutun
2. Doctrine'deki schema.yml gibi şema yapılandırma dosyası yok
3. Mevcut şemayı bağlantıdan okuyabilir ve diğer uygulama kurulumlarında aynı şemayı temsil etmek yerine yeni geçiş betiği oluşturabilir.

Taşıma aracımı yazmaya başladım ve bugün beta sürümüm var.

Bu konuyla ilgileniyorsanız lütfen deneyin. Lütfen bana gelecekteki istekleri ve hata raporlarını gönderin.

Kaynak kodu: bitbucket.org/idler/mmp/src İngilizce'ye Genel Bakış: bitbucket.org/idler/mmp/wiki/Home Rusça'ya Genel Bakış: antonoff.info/development/mysql-migration-with-php-project

Kullandığım http://code.google.com/p/oracle-ddl2svn/

Ben de bu konuyla ilgileniyorum.

Orada Django wiki bu konuyla ilgili bazı tartışmalar .

İlginç bir şekilde, CakePHP'nin sadece cake schema generatekomut kullanarak yerleşik şema sürümlemesine sahip olduğu görülüyor .

MySQL için

Yeni bir DB'ye indiğimde:

Öncelikle yapıyı kontrol ediyorum:

mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB1_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_1.sql
mysqldump --no-data --skip-comments --skip-extended-insert -h __DB_HOSTNAME__ -u __DB_USERNAME__ -p __DB2_NAME__ | sed 's/ AUTO_INCREMENT=[0-9]*//g' > FILENAME_2.sql
diff FILENAME_1.sql FILENAME_2.sql > DIFF_FILENAME.txt
cat DIFF_FILENAME.txt | less

Stackoverflow kullanıcıları sayesinde, yapı farklılıklarını bulmak için bu hızlı betiği yazabilirim.

src: https://stackoverflow.com/a/8718572/4457531 & https://stackoverflow.com/a/26328331/4457531

İkinci adımda, verileri tabloya göre kontrol ediyorum mysqldiff. Biraz arkaik ama information_schemaverilere dayalı bir php döngüsü kesinlikle iş yapıyor

Sürüm oluşturma için aynı yöntemi kullanıyorum, ancak bir SQL güncelleme komut dosyasını (yükseltme veya geri alma) diff sonuçlarıyla biçimlendiriyorum ve sürüm numarası kuralını kullanıyorum (çeşitli değişikliklerle sürüm numarası bir ip adresi gibi görünüyor) .

initial version : 1.0.0
                  ^ ^ ^
                  | | |
structure change: - | |
datas added: -------- |
datas updated: --------

Veritabanı şemasının katı versiyonunu kullanıyorum (ayrı bir tabloda izleniyor). Komut dosyaları sürüm kontrolünde saklanır, ancak tümü herhangi bir değişiklik yapmadan önce mevcut şema sürümünü doğrular.

İşte SQL Server için tam uygulama (gerekirse aynı çözüm MySQL için de geliştirilebilir): SQL Server Veritabanı Şeması Sürümü Nasıl Korunur

Uzun bir araştırmadan sonra, beni tatmin etmeyen bazı 3. parti araçların veya Visual Studio proje türlerinin ya da sadece teori hakkında blogların olduğunu ancak uygulaması olmadığını anladım. Bu yüzden neredeyse bir yıldır kullanılan ve burada açıklanan bir çalışma sistemi uyguladım:

http://nalgorithm.com/2015/11/09/database-versioning-part-1/

ilgiye bağlı olarak daha çok yazmaya devam edecek.