FB ye ilk adimim
FB ye ilk adimim
Firebird ile mdb dosyami kullanmak istiyorum forumu saatlerdir okuyorum ama yinede anlamadim basitce nasil baglarim?
-
Ali Erdoğan
- Kıdemli Üye
- Mesajlar: 1026
- Kayıt: 11 Şub 2005 02:12
- Konum: İstanbul
Datapump yada benzeri bir program ile verilerini mdb formatından firebird e ihraç edebilirsin.
Eğer Ms Sql Server - Enterprise Manager varsa elinde onunla mdb den sql server a buradan da odbc ile firebird e ihraç yapabilirsin. Enterprise Manager ın ithal ve ihraç (export / import) araçları gerçekten çok güzel çalışıyor
Eğer Ms Sql Server - Enterprise Manager varsa elinde onunla mdb den sql server a buradan da odbc ile firebird e ihraç yapabilirsin. Enterprise Manager ın ithal ve ihraç (export / import) araçları gerçekten çok güzel çalışıyor
okumayı ve aramayı alıskanlık haline getirmez isek gelisemeyiz...
viewtopic.php?t=5800
viewtopic.php?t=5800
ÜŞENME,ERTELEME,VAZGEÇME
Okumakla sorunu olmayan birisinin diyecegi bir-iki kelime olacak:gkimirti yazdı:okumayı ve aramayı alıskanlık haline getirmez isek gelisemeyiz...
viewtopic.php?t=5800
-- Firebird'un limitleri konusunda cok yaniliyorsunuz. Sonsuz filan degil; bilakis 'undocumented' (kullaniciya bildirilmemis) bir hayli limiti ve sorunu var.
Bunlarin kisa bir listesi:
#- Undocumented table limit of about 35GB, an overflow may cause data corruption
#- Removing (garbage collecting) nodes from a non-selective index is extremely slow
#- Bigger page cache often means slower performance
#- Optimizer is not able to choose a good plan in many cases
#- International support is weak, a lot of bugs in the Unicode/MBCS handling
#- Lack of a fast backup/restore mechanism
#- Weak security and many known vulnerabilities
#- Requirement of exclusive database access for referential integrity declarations
#- Too few built-in functions
#- Unreliable database shutdown
Bu listeyi de FB'nin rakipleri degil; bizzatihi kendileri yayinladilar. Link burada:
http://www.firebirdsql.org/devel/engine ... p2006.html
Backup-restore problemlerinden bahsetmemisler. Bunun icin FB-Architect listesini takip etmeniz gerekiyor...
-- Verdiginiz linkte soyle bir soru cevap var:
Bu eskiden dogru idi ama artik degil. FB'nin ODS'si (On Disk Structure -- Diskteki Dosya Yapisi) ile Interbase artik uyumlu degil. Daha da otesi, FB'nin eski surumleri ile de degil.Interbase ile hazırladığım veritabanlarımı FireBird ile kullanabilir miyim?
Evet, Firebird ile Interbase 6 ve hatta daha önceki Interbase sürümlerinde hazırladığınız veritabanlarını kullanabilirsiniz.
Backup-restore gerekiyor ama bu da herzaman basarili olamiyor.
-- Verdiginiz linkte Yafill'den bahsediliyor. Bu artik yok. Firebird 2.x ile coktan birlestiler.
-- Jim Starkey'in (BigBadWolf) yazdigi Vulcan kodunun Firebird anadalina baglantisi v3.x ile yapilacak. Burasi iyi. Kotu olan, Jim Starkey'in Firebird Dev'den ayrilmis olmasi. Bu kotu. Cunku, o ayrilai beri FB'de bir arpa boyu gelisme goremedim --eldeki mevcudu derleyip yeni bir beta olarak yayinlamaktan baska.
-- Buyuk bir ihtimalle Vulcan kodu FB anadalina katilacak, ama, ondan sonrasi icin kisisel olarak benim pek umidim yok. Projenin sponsoru da yok pek, lider de ayrildi.
Ben bundan memnun degilim, kac senedir FB'nin evangelizmini yapyordum, ve FB'den --eh mertebesinden azbiraz yukarida-- memnundum. Ama, yeni bir projeye baslanacaksa, artik FB ile baslamanin ne derece dogru oldugunu dusunmek gerekiyor.
Kisisel kanaatim, su noktada, yeni projeler icin FB kullanmak yerine PostgreSQL kullanmak cok caha akillica olur.
PostgreSQL de eski PG degil. Windows'da native calisiyor. v8.1 ile birlikte tonlarca yenilik geldi --autosweep gibi mesela. FB ile yapip PG ile yapamayacaginiz bir sey benim aklima gelmiyor; ama, tersi oyle degil. PG'de cok daha ilginc zenginlikler var bence. Veri tipleri basta olmak uzere (FB'de native GUID kullanmagi deneyin bakalim
)Bunlarin yanisira, cok daha genis bir kullanici ve gelistirici kitlesi var. Devasa siretlerin de sponsorluguna sahipler. Kisaca, batmayacak birisi varsa o da PG gibi gorunuyor.
PG'yi Zeos bilesenleri ile kullanabilirsiniz.
Dolayisi ile, Delphi dunyasinin artik FB takimi tutmasi cok da yerinde olmuyor bence.
? Kafam daha da iyi karisti. O kadar cok veri tabani olduki hangisini sececegimi sasirdim hepsinin avantaj dezavantaj oyle affedilir cinsten degil...
Ama yinede access i cok sevmistim, tabii bana networkte ve fazla kayitta cok problem cikartti. Yeni cikan veri tabanlari artik bu programlar ilede uyumsuz.
Ama yinede access i cok sevmistim, tabii bana networkte ve fazla kayitta cok problem cikartti. Yeni cikan veri tabanlari artik bu programlar ilede uyumsuz.
Kisisel kanaatim:pcman yazdı:? Kafam daha da iyi karisti. O kadar cok veri tabani olduki hangisini sececegimi sasirdim hepsinin avantaj dezavantaj oyle affedilir cinsten degil...
Ama yinede access i cok sevmistim, tabii bana networkte ve fazla kayitta cok problem cikartti. Yeni cikan veri tabanlari artik bu programlar ilede uyumsuz.
1) Lisans sorunu olmayan ve acik kaynak kod istiyorsaniz, PostgreSQL.
Bugun icin en iyi alternatif bu. Kimsenin de (yani, Oracle ya da M$) satin alip oldurmek ihtimali yok.
2) Delphi ile olsun istiyorsaniz, ticari amaclarla kullanacaksaniz --yani parayla alacaksaniz-- MexusDB ( http://www.nexusdb.com ). Su anda Delphi'de bundan daha iyisi yok. MS SQL'den filan da iyi sayilir. Ve, ayrica da hizli. Su andaki surumu 2.0x iyi, ama, full-text search istiyorsaniz bunu v3.x getirecek.
Benim NexusDB ile ilgili tek endisem, bu sirketi birilerinin satin alip tarihe gommek ihtimalidir. Su anda gundemde degil, ama, belli mi olur.
3) Bir iki sene sonra, gercekten kanatlanacak bir ey istiyorsaniz, lisans konusunda gri bolge sizi rahatsiz etmeyecekse, MySQL kullanacaksiniz. Cunku, MySQL iki onemli atilim yapti.
Birincisi, yukarida bahsettigim, Firebird gurusunu (Jim Starkey) MySQL'ciler transfer ettiler. http://www.infoworld.com/article/06/02/ ... res_1.html
Ikincisi de, Jim'in kendi urunu olan NetfraStracture'dan ( http://www.netfrastructure.com ) da bir cok acidan iyi olan, alisilmadik hizlara cikabilen bir veritabanini da MySQL bunyesine katti. Urunun ismi Solid Database ( http://www.solidtech.com ). Cok yetenekli bir sey. Telekom sektorunde, bankacilikta, kredi kartlari gibi cok suratli calismasi gereken islerde kullaniliyor.
Karar sizin..
Sanirim yaslaniyorum yeni cikan herseyi ogrenmek istemiyorum belki de onun icin bir dil ile calismak istiyorum. Cunku yenilikleri/yeni eklentileri optimum kullanabilmek icin belli bir sure kavramaya calisiyorum tam etkin kodlar yaziyorum bir alternatif cikiyor bu yuzden 5. kusak programla dilleri cikti cikali programciligi eskisi kadar sevmiyorum.
Merhaba,
Evet Sık Sorulan Sorular FireBird 1.5'a göre hazırlandı. Belki 2.0 çıkınca yenilemek gerekebilir.
Sayın @MuzAn,
Bahsettiğiniz limitler acaba bizim için ne kadar geçerli, beni ilgilendiren o. FireBird, Interbase 7 dosyalarını okumuyormuş : ee zaten benim IB 7 dosyam yok. 30 TB üstüne çıkmıyormuş, benim için 30 TB bir veritabanı çok çok uzak ihtimal. Firebird benim şu ana kadar gördüğüm en başarılı veritabnlarından ve open source projelerden biri. Bunun böyle devam etmesini umuyorum.
PostgreSQL elbetteki iyi bir veritabanı ama ben hiç alakadar olmadım. Kullanan birkaç arkadaşım var. Ama PostgreSQL benim kafamda Linux ile özdeşleşmiş durumda
Benim kişisel tercihim halen Firebird yönünde ama yarın dediğiniz gibi PostgreSQL daha avantajlı ise onu da kullanırım.
Teşekkürler.
Evet Sık Sorulan Sorular FireBird 1.5'a göre hazırlandı. Belki 2.0 çıkınca yenilemek gerekebilir.
Sayın @MuzAn,
Bahsettiğiniz limitler acaba bizim için ne kadar geçerli, beni ilgilendiren o. FireBird, Interbase 7 dosyalarını okumuyormuş : ee zaten benim IB 7 dosyam yok. 30 TB üstüne çıkmıyormuş, benim için 30 TB bir veritabanı çok çok uzak ihtimal. Firebird benim şu ana kadar gördüğüm en başarılı veritabnlarından ve open source projelerden biri. Bunun böyle devam etmesini umuyorum.
PostgreSQL elbetteki iyi bir veritabanı ama ben hiç alakadar olmadım. Kullanan birkaç arkadaşım var. Ama PostgreSQL benim kafamda Linux ile özdeşleşmiş durumda
Benim kişisel tercihim halen Firebird yönünde ama yarın dediğiniz gibi PostgreSQL daha avantajlı ise onu da kullanırım.
Teşekkürler.
En son mussimsek tarafından 24 Nis 2006 04:30 tarihinde düzenlendi, toplamda 1 kere düzenlendi.
-
Ali Erdoğan
- Kıdemli Üye
- Mesajlar: 1026
- Kayıt: 11 Şub 2005 02:12
- Konum: İstanbul
http://www.ibphoenix.com/main.nfs?a=ibp ... tem+Limits'
Yukarıdaki sınırlılıklardan sadece sonuncusu beni biraz bağladı. in listesinde 1499 dan fazla eleman olamıyor ancak bunu da alan in (a,b,c...) or alan in (1,2,3....0) şeklinde çözebiliyorum. Diğer sınırlıkların bir sorun yaratacağını zannetmiyorum.
Her şey gibi bu veri tabanın da sınırlılıkları var. Bu arada maksimum veri tabanı boyutu 30 TB olarak verilmiş. Bu büyüklükte bir depolama alanına sahip olabilmek için google da felan çalışıyor olmak lâzım sanırım.The significant restrictions are:
* Max indexes per table is 255 in Firebird 1.5x and 64 in Firebird 1.0x.
* Max size of an index key is 254 bytes and less for compound keys in Firebird V1.x. Firebird 2 and future versions allow keys up to 25% of the size of a database pages. Character columns that sort in dictionary order rather than byte order require more than one byte per character to represent their collating sequence. As a result, the effective limit on key size may be as low as 90 bytes for some languages. Version 2 will lift this restriction.
* Max number of conjuncts is 255. A conjunct is a pair of conditions combined with an AND.
WHERE F1 = 1 and F2 >= 2 and F2 = 5
is 3 conjuctions, but
WHERE F1 = 1 or F2 >= 2 or F2 = 5
is 1 conjunction
* Maximum size of a table is approximately 50Gb of compressed data, depending on the size of the records. A table with records that compress to 50 bytes can store approximately 50 Gb of compressed data. A table with records that compress to 500 bytes can store approximately 70Gb of compressed data. Version 2 will lift this restriction.
* Metadata names are restricted to 31 characters.
* The maximum size of a blob is 2Gb.
* Rows are restricted to 32767 bytes
* A database can contain no more than 32767 tables.
* The maximum size for a database is over 30 terabytes.
* Maximum number of elements in an IN list is 1499.
select name from phones where extension
in (0000, 0001, 0002 ... 1499);
Yukarıdaki sınırlılıklardan sadece sonuncusu beni biraz bağladı. in listesinde 1499 dan fazla eleman olamıyor ancak bunu da alan in (a,b,c...) or alan in (1,2,3....0) şeklinde çözebiliyorum. Diğer sınırlıkların bir sorun yaratacağını zannetmiyorum.
Selamlar,
Firebird Jim Starkey ile doğdu, doğrudur ama Jim Starkey öldüğünde Firebird bitecek mi sizce? Yada yapılan yazılımlar biz firmadan ayrıldığımızda biter mi sizce?
Ben bu şekilde düşünmüyorum FB bir projedir ve projenin elemanları değişir, haaa eski kurallar yenilerle bereber değişebilir bu da bir sonuç ama benim de izlediğim kadarı ile FB çok iyi yolda ilerliyor ve ayrıca sponsorsuz oluşu daha da iyi bir özellik diye düşünüyorum. Open Source ruhunu kaybettirmeyecektir en azından.
Ayrıca Versiyon yetiştirme kaygıları olmadığından daha da rahat bir geliştirme imkanı doğuracaktır. Kimseye yetişmek gibi bir derdi de yok.
Ticari kaygı devreye girdiğinde sorunlar da beraberinde patlak veriyor.
Verdiğiniz BUG'lar zaten Developer Listelerini takip edenlerce bilinmekte. ayrıca bizler de bazı BUG bildirimlerinde bulunuyoruz. Hatasız kul olmaz, önemli olan hataların sıklığı ve büyüklüğü.
Ayrıca kalkıp da kimsenin, özellikler listesine, aha işte bunlar da BUG'larımız dediğini ne duydum ne de gördüm
Sorun olacaktır, sorun olacaktır ama bu soruna nasıl bir çözüm bulunabildiğidir esas olan. Ben bir BUG yakalamıştım ve bildirdim, şu anda bu soruna bir çözüm bulunamıyor. Belki ileride bulunacak ama ben de çözülüp çözülmediğine dair (Versiyon 2.0'da test yapmadım) müsait bir zamanda deneyeceğim inşallah !!
Oyyyy boş zamanlarıma amma çok iş birikti
Kalın Sağlıcakla
Not : O boş zamanları bi bulabilsem
Firebird Jim Starkey ile doğdu, doğrudur ama Jim Starkey öldüğünde Firebird bitecek mi sizce? Yada yapılan yazılımlar biz firmadan ayrıldığımızda biter mi sizce?
Ben bu şekilde düşünmüyorum FB bir projedir ve projenin elemanları değişir, haaa eski kurallar yenilerle bereber değişebilir bu da bir sonuç ama benim de izlediğim kadarı ile FB çok iyi yolda ilerliyor ve ayrıca sponsorsuz oluşu daha da iyi bir özellik diye düşünüyorum. Open Source ruhunu kaybettirmeyecektir en azından.
Ayrıca Versiyon yetiştirme kaygıları olmadığından daha da rahat bir geliştirme imkanı doğuracaktır. Kimseye yetişmek gibi bir derdi de yok.
Ticari kaygı devreye girdiğinde sorunlar da beraberinde patlak veriyor.
Verdiğiniz BUG'lar zaten Developer Listelerini takip edenlerce bilinmekte. ayrıca bizler de bazı BUG bildirimlerinde bulunuyoruz. Hatasız kul olmaz, önemli olan hataların sıklığı ve büyüklüğü.
Ayrıca kalkıp da kimsenin, özellikler listesine, aha işte bunlar da BUG'larımız dediğini ne duydum ne de gördüm
Sorun olacaktır, sorun olacaktır ama bu soruna nasıl bir çözüm bulunabildiğidir esas olan. Ben bir BUG yakalamıştım ve bildirdim, şu anda bu soruna bir çözüm bulunamıyor. Belki ileride bulunacak ama ben de çözülüp çözülmediğine dair (Versiyon 2.0'da test yapmadım) müsait bir zamanda deneyeceğim inşallah !!
Oyyyy boş zamanlarıma amma çok iş birikti Kalın Sağlıcakla
Not : O boş zamanları bi bulabilsem
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Ben herhangi bir yerde 30 TB'den bahsetmedim. Yukaridaki yazima tekrar bakarsaniz orada listelenenlerin basinda "Undocumented table limit of about 35GB, an overflow may cause data corruption" geliyor.mussimsek yazdı: Bahsettiğiniz limitler acaba bizim için ne kadar geçerli, beni ilgilendiren o. FireBird, Interbase 7 dosyalarını okumuyormuş : ee zaten benim IB 7 dosyam yok. 30 TB üstüne çıkmıyormuş, benim için 30 TB bir veritabanı çok çok uzak ihtimal. Firebird benim şu ana kadar gördüğüm en başarılı veritabnlarından ve open source projelerden biri. Bunun böyle devam etmesini umuyorum.
Siz belki hic 30 GB buyuklugunde bir tablo sahibi olmayacaksiniz; ama, bu ebatta bir tablo sanildigi kadar da buyuk degil. Herhangi bir multimedia ya da document table'i bu ebatlara kolayca cikar.
Bunun tabii ki cludge cinsinden etrafindan dolanmak mumkundur; ama, burada onemli olan 'undocumented' olmasidir.. Baska bir deyisle, basiniza gelince, 'nicin oldu?' sorusuna cevap bile bulamayabilirsiniz.
Beni ilgilendiren, limitlerin azligi ya da coklugundan cok, 'gizli' ya da bilinmeyen limitler..
Haklisiniz. Ama, bu v8.1 ile degisti ve Win32 uzerinde PG cok kolay kurulur ve kullanilir hale geldi.PostgreSQL elbetteki iyi bir veritabanı ama ben hiç alakadar olmadım. Kullanan birkaç arkadaşım var. Ama PostgreSQL benim kafamda Linux ile özdeşleşmiş durumda
Dolayisi ile, arkadaslarimiza /denemeleri icin/ onermekte bir sakinca gormuyorum ben.
Evet. En saglikli bakis bu. Ben de, zaten, /yeni baslayacak projeler icin/ PG'yi oneriyorum. Daha dogrusu, PG'yi dikkate almagi oneriyorum.Benim kişisel tercihim halen Firebird yönünde ama yarın dediğiniz gibi PostgreSQL daha avantajlı ise onu da kullanırım.