SP içinden veritabanı ismini öğrenmek

[Ali Erdoğan]

Veri tabanı adına değişik sebeplerden dolayı ihtiyaç duyulabilinir. Zira linux ta da "ben kimim" gibi komutlar vardır. Ancak veri tabanı ismi içerisinden çalışma yılını vs. çekmek bence mantıklı değil. Adam bir deneme yapmak için veri2005 veri tabanını bir kopyasını alıp veri2005a adı ile kaydetmek isteyebilir ki buda yanlış bir istek değildir. Ancak veri tabanı ismine bakarak çalıştığımızda bu yöntem imkânsız olacaktır. Bunun yerine veri tabanın içerisindeki bir tabloda o veri tabanın hangi çalışma yılına ait olduğu saklanabilinir. Çok da kolay olacaktır. Hem de o veri kullanıcı tarafından değiştirilemeyeceğinden sorun çıkma olasılığı çok daha düşük olacaktır.

[fahrettin]

ben de sana nasreddin hocanın bindiği dalı kestiğini söylüyorum.
ağaçtan düşersin demek bir önyargıysa sence, kabul.
bindiğim dalı kessem bile düşmeyeceğim şekilde bir iskele sistemi geliştirilmesi lazım diye tutturursa, ne diycez kendisine?
Ben ihtiyaç duyulabilecek bir tasarım düşünemiyorum, birbirinin aynısı procedureleri çalıştırmak üzere ayrı ayrı yaratılıp optimizasyon sağlanmış bir sistemi aklım almıyor. ama FB hosting hizmeti veren bir firma herkese özel bir DB açabilir onu anlarım ama...
sysbase, oracle mssql kullanmıyor böyle şeyleri FB neden kullansın?
RDBMS sistemlerden FB ye geçen kullanıcılar hiç böyle bir kullanıma kalkışmıyorken, btrieve, paradox, isamdan gelenlerin buna kalkışmasını
anlayışla karşılayıp yanlış destek olmak doğru mu sence?

Ali Bey,
Firebird u henuz yogun olarak kullanmasam da ben de seviyor ve destekliyorum. Ileride kullanmayi da planliyorum. Bence verilmesi gereken ilk cevap Firebird de veritabanı adını alamazsınız olmalıydı. En azından bu kadar uzayan basliktan ben bunu cikardim. Problem degil insanlar bir sekilde cozer dertlerini... Fakat bir mesele Firebird de yok ise buna kimsenin hic bir sekilde ihtiyaci olmaz fikrinin cikis noktasi bence yanlis...

Simdi kisa ihtiyaci gormenizi saglamaya calisacagim...
Bir proje dusunun merkez ve ona bagli bir cok bayi veya acente denilecek alt subeler. 1 merkez var buna karsilik da yuzlerce sube. Subelerin DB adi x_sube olsun. Merkezdeki DB adi da x_merkez. Yani topu topu 2 tane DB tasarımınız var. Bu iki DB de de birbirine benzeyen yapılar var. Hatta tamamen birbirinin aynı tablolar var. Hem sube hem de merkez tarafinda cok komplesk bir islem blogunu SP haline getirmissiniz. Bu SP nin kullandigi tabloların çoğu her iki DB de aynı tablolar. SP nin asil işlem yaptigi tablolar aynı iken yani aslı işlem blogu her iki tarafta da tek iken sadece bir kac satirlik bir DB adı kontrolu ile farkli olan islemi yapmak varken her iki tarafa da ayrı SP yapmak bence hiç akıllıca degil... Benim tercihim tek bir SP yapmak olurdu nitekim oyle de oldu. SP uzerinde yaptiginiz gelistirmelerde yapılacak tek sey yeni halini diger DB ye de aktarmak. Aksi taktirde her degisiklikte ya gidip ayni degisikligi diger tarafta da yapılmalı ki bu da hataya çok daha açık olurdu....

RDBMS sistemlerden FB ye geçen kullanıcılar hiç böyle bir kullanıma kalkışmıyorken, btrieve, paradox, isamdan gelenlerin buna kalkışmasını
anlayışla karşılayıp yanlış destek olmak doğru mu sence?

Kesinlikle değil. Zaten bu forumda 2 yılı aşan sürede mücadele ettiğimiz temel problemlerden biris de bu... Bu gune kadar bu amaçla yazdık çizdik. Seminerler verdik hep birlikte... Bu fikrinizin sonuna kadar arkasındayım...
Dediğim gibi takıldığım nokta biraz peşin önyargı gostermenize idi...

Saygılarımla....

[Terminator]

>>
Ali Bey,
Firebird u henuz yogun olarak kullanmasam da ben de seviyor ve destekliyorum. Ileride kullanmayi da planliyorum. Bence verilmesi gereken ilk cevap Firebird de veritabanı adını alamazsınız olmalıydı. En azından bu kadar uzayan basliktan ben bunu cikardim. Problem degil insanlar bir sekilde cozer dertlerini... Fakat bir mesele Firebird de yok ise buna kimsenin hic bir sekilde ihtiyaci olmaz fikrinin cikis noktasi bence yanlis...
>>
Fahrettin kardeşim,
anlamadığın yer burası, FB de yok diye bişey demedim, FB bunu yapabilen belki de tek RDBMS dir. Ama bunun yapılabiliyor gibi görülmesi
kötüye kullanılması için değildir. FB de veritabanının adını alamazsın diye bişey olur mu ya? DB nin adını bilmesen nasıl bağlanacaksın? hadi diyelim
alias kullandın ismi güvenlik amaçlı gizli, demek ki adıyla iş yapmaman gerekiyor. bikini üstüne türban takarak ahlak şovu yapılmaz.
FB olmayan ve standartlarda olan şeyler zaten itiraz edilmeyen sürekli ekleniyor. hatta FB dünyadaki standartların pek çoğunun ilk mucididir.
Ben bunca yıldır FB camiasındayım ve gönülden takip ederim ama
bu sizin tutturduğunuz istekle hiç karşılaşmadım. bu tarz bir kullanım, profesyonelce değil amatörce. bu ihtiyaç, bir teknik yetersizliğin sonucu.
FB veritabanı 1.5 MB lık bir EXE ise ve 20 yıldır obezite yakalanmadıysa sebebi akla mantığa bilime, yapısına uymayan istekleri yapmamasıdır.
yapan varsa ona gidin der FB cüler. FB profesyonel uzmanların sistemidir.
FB herkes içindir, canınız ne isterse yapabilrisiniz diyen yok! tam tersi.
bu belki FB ün yayılma hızını düşük tutuyor ama, emin adımlarla yürüyor.
FB ü beğenmeyen, yeteneksiz bulan, başka sistem kullansın, bir sürü sistem var, hiç bir FB çü aa neden FB kullanmıyorsun gel FB kullan diye tutturmaz.


<<
Simdi kisa ihtiyaci gormenizi saglamaya calisacagim...
Bir proje dusunun merkez ve ona bagli bir cok bayi veya acente denilecek alt subeler. 1 merkez var buna karsilik da yuzlerce sube. Subelerin DB adi x_sube olsun. Merkezdeki DB adi da x_merkez. Yani topu topu 2 tane DB tasarımınız var. Bu iki DB de de birbirine benzeyen yapılar var. Hatta tamamen birbirinin aynı tablolar var. Hem sube hem de merkez tarafinda cok komplesk bir islem blogunu SP haline getirmissiniz. Bu SP nin kullandigi tabloların çoğu her iki DB de aynı tablolar. SP nin asil işlem yaptigi tablolar aynı iken yani aslı işlem blogu her iki tarafta da tek iken sadece bir kac satirlik bir DB adı kontrolu ile farkli olan islemi yapmak varken her iki tarafa da ayrı SP yapmak bence hiç akıllıca degil... Benim tercihim tek bir SP yapmak olurdu nitekim oyle de oldu. SP uzerinde yaptiginiz gelistirmelerde yapılacak tek sey yeni halini diger DB ye de aktarmak. Aksi taktirde her degisiklikte ya gidip ayni degisikligi diger tarafta da yapılmalı ki bu da hataya çok daha açık olurdu....
>>

Örneğin çok kötü. vereceğin hiçbir örnek, beni ikna edemez, benim
ilgi ve tecrübe alanım, performans, optimizasyon ve veritabanı sistemleridir. Veritabınında herhangi bir flagla, tabloyla, generatorle tutabileceğin bir özelleştirme bilgisini kalkıp DB adı üzerinden yapmakta ısrar etmen anlaşılır bişey değil. hadi btrieve kullanıyorsun ve recordların her birinde aynı bilgi tekrarlamasın, yazacak başka bir yer de yok diye dosya adını kullandın diyelim.. ya kardeşim bu bir RDBMS! dünyada türünün ilk örneği, bir çok teknolojide önder üstelik.
senin verdiğin örnek arkadaşın projesinden farklı, seninki dağıtık mimari.
senin verdiğin örnek sistemde dosya adıyla projeyi tasarlayan bir iş arkadaşım benim yanımda barınamaz. ya ben giderim ya da onu basit işlere kaydırırım, ortamın genel kalitesine bağlı olarak.

[fahrettin]

vereceğin hiçbir örnek, beni ikna edemez

Emin olun sizi çok iyi anlıyorum Ali Bey....
Bu konu hakkında aklıma gelen şu söz dışında söyleyeceğim ilave bir şey yok....

Önyargıyı yıkmak, atomu parçalamaktan daha zordur.

Saygılarımla.....

[Terminator]

vereceğin hiçbir örnek, beni ikna edemez

Emin olun sizi çok iyi anlıyorum Ali Bey....
Bu konu hakkında aklıma gelen şu söz dışında söyleyeceğim ilave bir şey yok....

Önyargıyı yıkmak, atomu parçalamaktan daha zordur.

Saygılarımla.....

Haklısın!
sizi ikna etmektense soğuk füzyon deneylerine başlarım daha iyi..
Einstein bir de şunları demiş Fahrettin bey kardeşim:
"Zaman konusundaki eski düşünce ve açıklamalarımda yanıldığımı kabul ediyorum, bunu düzeltmeye çalışıyorum."

"Önemli problemlerimizi, onları yarattığımız bilinçlilik seviyesinde çözemeyiz."
( eski yıllarda mıcıkladığım homepageimden: http://www.geocities.com/ali_gokcen )


Salih, arkadaşım,
o dalı kesebilirsin canım, dalın ne tarafında oturduğun seni ilgilendirir haklısın. Benim gibi önyargılı birinin bu topice yazması bile hata.
ben çekiliyorum, bu tip senaryolara fikren bile olsa katılmıycam artık.
Önyargılarımla sizleri yanıltmak istemem, belki de 2*2 5 ediyodur
kim garanti verebilir ki..

[Salih]

Arkadaşım,

Bu isteğini oldukça tuhaf bulmakla birlikte FB de bildiğim kadarıyla böyle bir şey yok... Bence aslında gerek de yok. Veri tabanlarının yıla göre ayrılması sakıncalıdır ve yanlıştır.. Bir işletmede bir tane veritabanı olmalıdır. Sen yıllara ilişkin bilgileri, veritabanı içindeki tabloların primary key alanını kullanarak ayırmalısın. Kolay gelsin...
-------------
Bir konuyu benden daha az bilenlere saldırmak benim tavrım değil. Zaten bu forumların amacı da bilmeyenlere yardımcı olmak değil mi ?

Bu tartışmadan da birşeyler öğrendim, kar hanesine düşen bu oldu... Herkese teşekkürler...

Saygılar, sevgiler...

[sadettinpolat]

ismi, diski, serveri ve pathi her zaman değişebilecek bir dosyayı ne diye
SP de ihtiyaç duyarlar anlamış değilim.

veritabanını adı sürekli değişir değişmez çok önemli değil. bizim işimiz zaten değişimlere ayak uydurmak. dosya adı değişiyorda tabloların içeriği değişmiyor mu? hiç değişmeden yerinde duran birşey var mı?

arkadaşın ihtiyacı ne doğrultudarı bilemem ama şahsen veritabanlarıma farklı farklı isimler vermek bana cazip gelmiyor. ileride başıma açacağı sorunları çok iyi tahmin edebiliyorum ama arkadaşın başka bir çaresi yoksa mecburen bu şekilde kullanacaktır. sistemi yanlış veya doğru tasarlamış orasına birşey diyemem.

şahsen ben bir kaç veritabanı kullanmam gereken yerlerde veritabanının içerisine ihtiyaç duyacağım bilgileri koyuyorum lazım olursa ordan okuyup işimi hallediyorum ve son olarak "hiçbirşey dışarıdan göründüğü gibi değildir" sözünü hatırlatıyorum