Kod ile veritabanı oluşturmak

[KoPilot]

Merhaba;
Arkadaşlar, daha önce sorunsuz bir şekilde kod ile veritabanı oluşturdum ve kullandım fakat veritabanın da generatörler ve 1-2 trigger dışında sp ve trigger yoktu. Şimdi bütün işlemlerin yükünü, sp'ler ve triggerlarla, veritabanına yükledim. Yükledim yüklemesine de ibexpert ile "extract metadata" ile veritabanımın ddlsini alıp ibscripte ekliyorum, veritabanını oluşturuyor ama sp'ler tam olarak oluşmuyor dolayısıyla veritabanı çalışmıyor. SQL koduna baktım çok saçma bi düzeni var gibi geldi bana. Örneğin, önce sp oluşturuluyor sonra tablo oluşturuluyor sonra triger oluşturuluyor sonra sp'nin geri kalan bölümü alter ile ekleniyor yani saçma bir düzen.
Normalde bu SQL kodu böylemidir yoksa ibexpertin farklı bir ayarı mı var?
Kodla oluşturduğum veritabanım düzgün olarak çalışması için ne yapmalıyım, siz nasıl yapıyorsunuz?
Kullandığım veritabanı firebird 2.5.x

[freeman35]

Bir almanın yaptığı bir sistem hemde yıllardır çalışan bir sistem, "saçma"
ibexpert e sorabilirsin, alman olduklarından buna mutlaka cevap vereceklerdir.

[sabanakman]

Veritabanı yapılarını (ddl) script olarak çıkartmak enteresan senaryolar barındırabiliyor. Mesela bir "trigger" da kullanılan fonksiyon başka bir tablodan bilgi çekiyor olabilir. O tabloda calculated (computed) field (hesaplanmış alan) bulunabilir. Bu alan başka fonksiyon o fonksiyon bir stored procedure kullanıyor olabilir. Hatta bir fonksiyon başka prosedüre veya fonksiyonları ya da bir prosedür başka fonksiyon veya prosedürleri kullanabileceği için birbirlerine gerek duyacaktır. Bu zinciri doğru sıralama ile tutturmak neredeyse imkansız gibi bir durum olabiliyor. Fakat burada kendimce bir tavsiyem olacak. Teorik olarak çalışır gibi gelse de vakit bulup bir çalışma yapma fırsatım bulunmadı. Sıralama bu şekilde gözetilirse başarılı bir veritabanı ddl oluşturmak mümkün olacaktır.

-Öncelikle kullanıcı tanımlı tipler varsa bunlar oluşturulmalı
-Tüm fonksiyon ve prosedürleri aynı parametrik yapıda kodsuz olarak create script kodu oluşturulmalı.
Örnek:

Kod: Tümünü seç

CREATE PROCEDURE dbo.spTest @CariKodu nvarchar(25), @Sonuc nvarchar(100) OUTPUT
AS

veya

Kod: Tümünü seç

CREATE FUNCTION dbo.fnToInteger(@s_Val nvarchar(50), @DefVal bigint=NULL)
RETURNS bigint
AS

gibi.
-Tabloların sadece alanları ile (Primary Key dahil olacak şekilde) create eden scriptin oluşturulması. Tüm fonksiyon ve prosedürler içi boş da olsa hesaplama alanları problem çıkarmayacaktır. Tabi henüz hesap yapma kabiliyetleri yoktur tabi.
-Tablolara ait indeksler ve ilişkilerin tanımlarının oluşturulması.
-Tablolara ait triggerların oluşturulması.
-Bütün veritabanı elemanları oluşturulduktan soran tüm prosedüre ve fonksiyonların alter edilerek içlerinin doldurulması.
Örnek:

Kod: Tümünü seç

ALTER PROCEDURE dbo.spTest @CariKodu nvarchar(25), @Sonuc nvarchar(100) OUTPUT
AS
selet @Sonuc=Adres from Musteri where CariKodu=@CariKodu

veya

Kod: Tümünü seç

ALTER FUNCTION dbo.fnToInteger(@s_Val nvarchar(50), @DefVal bigint=NULL)
RETURNS bigint
AS
 if isNumeric(@s_Val)=1
    return cast(@s_Val as int)
 else
    return null

gibi. Bu şekilde nerede hangi prosedüre veya foksiyona ihtiyaç olsa bile bu içi boş da olsa mevcut olduğundan create scriptleri hata vermeyecek ama tüm sql sorgu işini bitirdikten sonra veritabanı (teorik olarak) eksiksiz oluşturulacaktır. Hazır 3. parti uygulamalar arasında bu gibi karmaşık yapıyı çözen var mıdır pek araştırmadım ama kendi ddl sql çıkarma uygulamamızı geliştirirsek bu yapıyla çözülebilir gibi sanki .

[KoPilot]

Bir almanın yaptığı bir sistem hemde yıllardır çalışan bir sistem, "saçma"
ibexpert e sorabilirsin, alman olduklarından buna mutlaka cevap vereceklerdir.

Saçmalamışlar demek istemedim zaten, "çıkan ddl saçmaymış gibi geldi bana" demek istedim ki zaten @sabanakman hocamın açıklaması beni tatmin etti ve ne demek istediğimi tam olarak anlatmış @freeman35 hocam.
Yoksa alman disiplini için bişey söylersem ağzım eğilir, bunu biliyorum amenna

[KoPilot]

Veritabanı yapılarını (ddl) script olarak çıkartmak enteresan senaryolar barındırabiliyor. Mesela bir "trigger" da kullanılan fonksiyon başka bir tablodan bilgi çekiyor olabilir. O tabloda calculated (computed) field (hesaplanmış alan) bulunabilir. Bu alan başka fonksiyon o fonksiyon bir stored procedure kullanıyor olabilir. Hatta bir fonksiyon başka prosedüre veya fonksiyonları ya da bir prosedür başka fonksiyon veya prosedürleri kullanabileceği için birbirlerine gerek duyacaktır. Bu zinciri doğru sıralama ile tutturmak neredeyse imkansız gibi bir durum olabiliyor. Fakat burada kendimce bir tavsiyem olacak. Teorik olarak çalışır gibi gelse de vakit bulup bir çalışma yapma fırsatım bulunmadı. Sıralama bu şekilde gözetilirse başarılı bir veritabanı ddl oluşturmak mümkün olacaktır.

-Öncelikle kullanıcı tanımlı tipler varsa bunlar oluşturulmalı
-Tüm fonksiyon ve prosedürleri aynı parametrik yapıda kodsuz olarak create script kodu oluşturulmalı.
Örnek:

Kod: Tümünü seç

CREATE PROCEDURE dbo.spTest @CariKodu nvarchar(25), @Sonuc nvarchar(100) OUTPUT
AS

veya

Kod: Tümünü seç

CREATE FUNCTION dbo.fnToInteger(@s_Val nvarchar(50), @DefVal bigint=NULL)
RETURNS bigint
AS

gibi.
-Tabloların sadece alanları ile (Primary Key dahil olacak şekilde) create eden scriptin oluşturulması. Tüm fonksiyon ve prosedürler içi boş da olsa hesaplama alanları problem çıkarmayacaktır. Tabi henüz hesap yapma kabiliyetleri yoktur tabi.
-Tablolara ait indeksler ve ilişkilerin tanımlarının oluşturulması.
-Tablolara ait triggerların oluşturulması.
-Bütün veritabanı elemanları oluşturulduktan soran tüm prosedüre ve fonksiyonların alter edilerek içlerinin doldurulması.
Örnek:

Kod: Tümünü seç

ALTER PROCEDURE dbo.spTest @CariKodu nvarchar(25), @Sonuc nvarchar(100) OUTPUT
AS
selet @Sonuc=Adres from Musteri where CariKodu=@CariKodu

veya

Kod: Tümünü seç

ALTER FUNCTION dbo.fnToInteger(@s_Val nvarchar(50), @DefVal bigint=NULL)
RETURNS bigint
AS
 if isNumeric(@s_Val)=1
    return cast(@s_Val as int)
 else
    return null

gibi. Bu şekilde nerede hangi prosedüre veya foksiyona ihtiyaç olsa bile bu içi boş da olsa mevcut olduğundan create scriptleri hata vermeyecek ama tüm sql sorgu işini bitirdikten sonra veritabanı (teorik olarak) eksiksiz oluşturulacaktır. Hazır 3. parti uygulamalar arasında bu gibi karmaşık yapıyı çözen var mıdır pek araştırmadım ama kendi ddl sql çıkarma uygulamamızı geliştirirsek bu yapıyla çözülebilir gibi sanki .

@sabanakman hocam açıklama için çok teşekkür ederim. Benim sorunum tam olarak söylediğiniz gibi olduğunu sanıyorum çünkü bir sürü farklı calculated alan ve hatta delphi içinden trigger'a gönderilen parametreler var. Dolayısıyla veritabanı oluşturuluyor ama (x tablosu bulunamadı, y alanı farklı) gibi normalde olmayan hatalar veriyor.
İlginiz için çok teşekkür ederim.

[freeman35]

bir hatayı takip et, hata kesinlikle senden kaynaklıdır. Yani var olan sistem çalışıyor olabilir, ama oraya bir şeyler eklerken, db boş değildi değil mi? ddl ise boş bir db create ediyor.
@sabanakman açıklamış nedenini. sen gene almanın yaptığınla git bence hatayı bulmak istiyorsan, computed fieldları takip et, yok bana acil çözüm diyorsan, ddl çıkartırken, önce domain ve table ları extract et, sonra geri kalanını. yani iki ddl olsun. %99 un üzerinde ihtimal sorun, computed alanları ddl in sonunda ekler ibexpert, trigger sp lerde sorun çıkmasada, table ddl lerinde ve/veya diğer table daki bir computed alanı kullandıysan, create esnasında o alan olmadığından hata alırsın. buna çözüm, create table sıralamalarını değiştirmek olabilir.
Ama bu hataların sebebi, lazım yaptım oldu işidir. yani tasarım hatası. gerekiyor diye bir şey eklemek olabilr, ama programcılık, bunun ilerdeki maliyeti ne olabiliri hesaplamaktır, ileri programcılık ise ki bu tecrübe gerektirir, ileride gerekebilecekleri varsayıp tasarımı ona göre yapmaktır.
Bir başka çok basit ilkel bir çözüm daha, var olan db yi clone la, içindeki tüm dataları sil, tüm table ları sıfırla. sonra db yi backup restore et, al sana istediğin db nin boş hali
kolay gele

[sabanakman]

Bir başka çok basit ilkel bir çözüm daha, var olan db yi clone la, içindeki tüm dataları sil, tüm table ları sıfırla. sonra db yi backup restore et, al sana istediğin db nin boş hali
kolay gele

Ne yalan söyleyeyim. Kendi uygulamalarımda bu yöntem daha sağlıklı gelmekte ve kullanmaktayım. Fakat genel kullanım için bir araç geliştirme fikri de yıllardır aklımı kemirip duruyor.

[freeman35]

Bu kötü bir şey değil ki. Bende arada kullanıyorum. Programcılıkta "kötü" çalışmayan, sorun çıkartan, gereksiz vakit kaybettiren manasında kullanmak gerekir.
Yukarıda bahsettiğim yöntem ilkel midir? Evet ilkeldir ve basittir. Ama kesin ve en pratik çözümdür. sakıncaları, her seferinde müşteri istediğinde yapmak zorunda kalırsın vs vs.
Bence araç geliştirmek vakit kaybı. ddl i extract edip onun üzerinde hataları vs giderip, parça parça script i execute etmek daha mantıklı çözüm. Ben eski programlarımda böyle yapıyordum. Şimdi aklıma geldi yukarıda bahsettiğim kopyalama yöntemini unigui projemde kullanıyorum. IIS server o günleri görebileceksem linux tada db scriptle oluşturmaya uğraşmayacağım mesela.

[KoPilot]

bir hatayı takip et, hata kesinlikle senden kaynaklıdır. Yani var olan sistem çalışıyor olabilir, ama oraya bir şeyler eklerken, db boş değildi değil mi? ddl ise boş bir db create ediyor.
@sabanakman açıklamış nedenini. sen gene almanın yaptığınla git bence hatayı bulmak istiyorsan, computed fieldları takip et, yok bana acil çözüm diyorsan, ddl çıkartırken, önce domain ve table ları extract et, sonra geri kalanını. yani iki ddl olsun. %99 un üzerinde ihtimal sorun, computed alanları ddl in sonunda ekler ibexpert, trigger sp lerde sorun çıkmasada, table ddl lerinde ve/veya diğer table daki bir computed alanı kullandıysan, create esnasında o alan olmadığından hata alırsın. buna çözüm, create table sıralamalarını değiştirmek olabilir.
Ama bu hataların sebebi, lazım yaptım oldu işidir. yani tasarım hatası. gerekiyor diye bir şey eklemek olabilr, ama programcılık, bunun ilerdeki maliyeti ne olabiliri hesaplamaktır, ileri programcılık ise ki bu tecrübe gerektirir, ileride gerekebilecekleri varsayıp tasarımı ona göre yapmaktır.
Bir başka çok basit ilkel bir çözüm daha, var olan db yi clone la, içindeki tüm dataları sil, tüm table ları sıfırla. sonra db yi backup restore et, al sana istediğin db nin boş hali
kolay gele

Eyvallah @freeman35 hocam, bütün öğretilerinizi kaydettim. Teşekkür ederim.

Bir başka çok basit ilkel bir çözüm daha, var olan db yi clone la, içindeki tüm dataları sil, tüm table ları sıfırla. sonra db yi backup restore et, al sana istediğin db nin boş hali
kolay gele

Şu anda aynen böyle kullanıyorum zaten.