Bu makalenin amacı bir kütüphane örneğini kullanmaktır. şema koruyucusu PostgreSQL DBMS'yi kullanarak PHP projelerinde veritabanları geliştirme sürecini önemli ölçüde basitleştirebilecek araçları gösterir.

Bu makaledeki bilgiler öncelikle PostgreSQL yeteneklerinden en iyi şekilde yararlanmak isteyen ancak veritabanına yerleştirilen iş mantığını sürdürmekte sorun yaşayan geliştiriciler için faydalı olacaktır.

Bu makale, iş mantığını bir veritabanında saklamanın avantajlarını veya dezavantajlarını açıklamayacaktır. Seçimin okuyucu tarafından zaten yapıldığı varsayılmaktadır.

Aşağıdaki sorular dikkate alınacaktır:

1. Bir sürüm kontrol sisteminde (bundan sonra VCS olarak anılacaktır) bir veritabanı yapısı dökümü hangi biçimde saklanmalıdır?
2. Bir dökümü kaydettikten sonra veritabanı yapısındaki değişiklikler nasıl izlenir?
3. Veritabanı yapısındaki değişiklikler, çakışmalar ve dev geçiş dosyaları olmadan diğer ortamlara nasıl aktarılır?
4. Birkaç geliştiricinin bir proje üzerinde paralel çalışma süreci nasıl organize edilir
5. Veritabanı yapısındaki daha fazla değişikliğin üretim ortamına güvenli bir şekilde nasıl dağıtılacağı
   

   Şema Kaleci dilde yazılmış saklı prosedürlerle çalışmak üzere tasarlanmıştır PL/pgSQL. Diğer dillerle test yapılmadığından kullanımı o kadar etkili olmayabilir veya mümkün olmayabilir.

VCS'de veritabanı yapısı dökümü nasıl saklanır

Kütüphane şema koruyucusu bir işlev sağlar saveDumpveritabanındaki tüm nesnelerin yapısını ayrı metin dosyaları olarak kaydeden. Çıktı, VCS'ye kolayca eklenebilecek gruplandırılmış dosyalara bölünmüş, veritabanı yapısını içeren bir dizindir.

Birkaç örnek kullanarak bir veritabanındaki nesneleri dosyalara dönüştürmeye bakalım:

Nesne türü
düzen
isim
Dosyanın göreceli yolu

tablo
halka açık
hesapları
./public/tables/accounts.txt

Saklı yordam
halka açık
yetki(hash bigint)
./public/functions/auth(int8).sql

Представление
rezervasyon
tarifeler
./booking/views/tariffs.txt

Dosyaların içeriği, belirli bir veritabanı nesnesinin yapısının metinsel bir temsilidir. Örneğin, saklı yordamlar için dosyanın içeriği, bloktan başlayarak saklı yordamın tam tanımı olacaktır. CREATE OR REPLACE FUNCTION.

Yukarıdaki tablodan da görülebileceği gibi dosyanın yolu, nesnenin türü, şeması ve adı ile ilgili bilgileri saklar. Bu yaklaşım, veritabanındaki değişikliklerin dökümü ve kod incelemesinde gezinmeyi kolaylaştırır.

uzatma .sql saklı yordam kaynak koduna sahip dosyalar için bu, IDE'nin dosya açıldığında veritabanıyla etkileşim kurmaya yönelik araçları otomatik olarak sağlaması için seçildi.

Bir dökümü kaydettikten sonra veritabanı yapısındaki değişiklikler nasıl izlenir?

Mevcut veritabanı yapısının bir dökümünü VCS'ye kaydederek, döküm oluşturulduktan sonra veritabanı yapısında değişiklik yapılıp yapılmadığını kontrol etme fırsatını elde ediyoruz. Kütüphanede şema koruyucusu veritabanı yapısındaki değişiklikleri tespit etmek için bir işlev sağlanır verifyDump, yan etkiler olmaksızın farklar hakkında bilgi döndürür.

Kontrol etmenin alternatif bir yolu işlevi tekrar çağırmaktır. saveDump, aynı dizini belirterek ve değişiklikleri VCS'de kontrol edin. Veritabanındaki tüm nesneler ayrı dosyalara kaydedildiğinden, VCS yalnızca değiştirilen nesneleri gösterecektir.
Bu yöntemin ana dezavantajı, değişiklikleri görmek için dosyaların üzerine yazma gereğidir.

Veritabanı yapısındaki değişiklikler, çakışmalar ve dev geçiş dosyaları olmadan diğer ortamlara nasıl aktarılır?

fonksiyon sayesinde deployDump Saklı prosedürlerin kaynak kodu, normal uygulama kaynak koduyla tamamen aynı şekilde düzenlenebilir. Saklı yordam koduna yeni satırlar ekleyebilir/silebilir ve değişiklikleri sürüm kontrolüne anında iletebilir veya döküm dizininde ilgili dosyaları oluşturarak/silerek saklı yordamlar oluşturabilir/silebilirsiniz.

Örneğin, bir şemada yeni bir saklı yordam oluşturmak için public uzantılı yeni bir dosya oluşturmanız yeterli .sql dizinde public/functions, saklı yordamın kaynak kodunu blok dahil olmak üzere içine yerleştirin CREATE OR REPLACE FUNCTION, ardından işlevi çağırın deployDump. Saklı bir prosedürün değiştirilmesi ve silinmesi aynı şekilde gerçekleşir. Böylece kod hem VCS’ye hem de veritabanına aynı anda giriyor.

Herhangi bir saklı yordamın kaynak kodunda bir hata görünürse veya dosyanın adları ile saklı yordamın adları arasında bir tutarsızlık varsa, o zaman deployDump başarısız olacak ve hata metni görüntülenecektir. Döküm ve geçerli veritabanı arasındaki saklı yordamların uyumsuzluğu kullanıldığında imkansızdır. deployDump.

Yeni bir saklı yordam oluştururken doğru dosya adını manuel olarak girmenize gerek yoktur. Dosyanın uzantısına sahip olması yeterlidir .sql. Aramadan sonra deployDump hata metni, dosyayı yeniden adlandırmak için kullanılabilecek doğru adı içerecektir.

deployDump bir işlevin veya dönüş türünün parametrelerini ek eylemlere gerek kalmadan değiştirmenize olanak sağlarken, klasik yaklaşımda yapmanız gerekenler
ilk önce yürüt DROP FUNCTIONve ancak o zaman CREATE OR REPLACE FUNCTION.

Ne yazık ki, bazı durumlar var deployDump değişiklikleri otomatik olarak uygulayamıyor. Örneğin, en az bir tetikleyici tarafından kullanılan bir tetikleme işlevi kaldırılırsa. Bu tür durumlar, geçiş dosyaları kullanılarak manuel olarak çözümlenir.

Saklı prosedürlerdeki değişiklikleri taşımaktan sorumluysanız şema koruyucusu, daha sonra yapıdaki diğer değişiklikleri aktarmak için geçiş dosyalarının kullanılması gerekir. Örneğin, geçişlerle çalışmak için iyi bir kütüphane doktrin/göçler.

Taşıma işlemleri lansmandan önce uygulanmalıdır deployDump. Bu, yapıda tüm değişiklikleri yapmanıza ve sorunlu durumları çözmenize olanak tanır; böylece saklı prosedürlerdeki değişiklikler daha sonra sorunsuz bir şekilde aktarılır.

Geçişlerle çalışmak aşağıdaki bölümlerde daha ayrıntılı olarak açıklanacaktır.

Birkaç geliştiricinin bir proje üzerinde paralel çalışma süreci nasıl organize edilir

Geliştirici tarafından iş makinesinde başlatılacak olan veritabanının tamamen başlatılması için bir komut dosyası oluşturmak ve yerel veritabanının yapısını VCS'de kaydedilen döküme uygun hale getirmek gerekir. En kolay yol, yerel veritabanının başlatılmasını 3 adıma bölmektir:

1. Örneğin çağrılacak temel yapıya sahip bir dosyayı içe aktarın. base.sql
2. Taşıma İşlemlerini Uygulama
3. Вызов deployDump

base.sql geçişlerin uygulandığı ve yürütüldüğü başlangıç ​​noktasıdır deployDumpYani, base.sql + миграции + deployDump = актуальная структура БД. Yardımcı programı kullanarak böyle bir dosya oluşturabilirsiniz. pg_dump. Kullanılmış base.sql yalnızca veritabanını sıfırdan başlatırken.

Tam veritabanı başlatma için betiği çağıralım refresh.sh. İş akışı şöyle görünebilir:

1. Geliştirici kendi ortamında başlatır refresh.sh ve mevcut veritabanı yapısını alır
2. Geliştirici, yeni işlevselliğin ihtiyaçlarını karşılamak için yerel veritabanını değiştirerek eldeki görev üzerinde çalışmaya başlar (ALTER TABLE ... ADD COLUMN ve benzeri)
3. Görevi tamamladıktan sonra geliştirici işlevi çağırır saveDumpVCS'deki veritabanında yapılan değişiklikleri işlemek için
4. Geliştirici yeniden başlatılıyor refresh.shO zaman verifyDumpartık taşıma işlemine dahil edilecek değişikliklerin bir listesini gösteriyor
5. Geliştirici tüm yapı değişikliklerini geçiş dosyasına aktarır, tekrar çalışır refresh.sh и verifyDumpve geçiş doğru şekilde derlenirse, verifyDump yerel veritabanı ile kayıtlı döküm arasında hiçbir fark göstermeyecek

Yukarıda açıklanan süreç gitflow ilkeleriyle uyumludur. VCS'deki her dal, dökümün kendi versiyonunu içerecektir ve dalları birleştirirken dökümler de birleştirilecektir. Çoğu durumda, birleştirme sonrasında ek bir işlem yapılmasına gerek yoktur, ancak farklı dallarda (örneğin aynı tabloda) değişiklikler yapılmışsa bir çakışma ortaya çıkabilir.

Bir örnek kullanarak bir çatışma durumunu ele alalım: bir dal var geliştirmek, hangi iki şubenin dallandığı: feature1 и feature2ile hiçbir çatışması olmayan geliştirmekama birbirleriyle anlaşmazlıkları var. Görev, her iki dalı da birleştirmektir. geliştirmek. Bu durumda öncelikle dallardan birinin birleştirilmesi önerilir. geliştirmekve sonra birleştir geliştirmek kalan daldaki anlaşmazlıkları çözer ve ardından son dalı birleştirir. geliştirmek. Çakışma çözümleme aşamasında, son daldaki geçiş dosyasını birleştirme sonuçlarını içeren son dökümle eşleşecek şekilde düzeltmeniz gerekebilir.

Veritabanı yapısındaki daha fazla değişikliğin üretim ortamına güvenli bir şekilde nasıl dağıtılacağı

VCS'de mevcut veritabanı yapısının bir dökümünün bulunması sayesinde, üretim veritabanının gerekli yapıya tam uyum açısından kontrol edilmesi mümkün hale gelir. Bu, geliştiricilerin amaçladığı tüm değişikliklerin üretim tabanına başarıyla aktarılmasını sağlar.

beri DDL PostgreSQL'de işlemselbeklenmedik bir hata durumunda "acısız" bir şekilde yürütebilmeniz için aşağıdaki dağıtım sırasına uymanız önerilir. ROLLBACK:

1. İşlemi başlat
2. Bir işlemdeki tüm geçişleri gerçekleştirin
3. Aynı işlemde yürütün deployDump
4. İşlemi tamamlamadan yürütün verifyDump. Hata yoksa çalıştırın COMMIT. Hata varsa çalıştırın ROLLBACK

Bu adımlar, sıfır kesinti süresi de dahil olmak üzere uygulama dağıtımına yönelik mevcut yaklaşımlara kolayca entegre edilebilir.

Sonuç

Yukarıda açıklanan yöntemler sayesinde, tüm iş mantığını ana uygulama kodunda uygulamaya kıyasla nispeten daha az geliştirme kolaylığından ödün verirken, "PHP + PostgreSQL" projelerinden maksimum performansı elde etmek mümkündür. Ayrıca veri işlemede PL/pgSQL genellikle daha şeffaf görünür ve PHP'de yazılan aynı işlevselliğe göre daha az kod gerektirir.

Kaynak: habr.com