Yıllık 100 milyon kayıt için ücretsiz DB?

[kefukar]

S.a.
Ortalama yıllık 100 milyon kayıt yapılacak bir proje için ücretsiz ve sorun çıkartmayacak ihtiyaçlarımı tam manasıyla BUG sız karşılayabilecek bir DB araştırması yapıyorum.
Şöyle düşünebilirsiniz 'Madem o kadar büyük proje paralı bişey kullan başın ağrımasın?' Ben projenin fiyatını son kullanıcı bazında arttırmak istemiyorum.
(Mecbur kalmadığım sürece...)

Seçenekler:

1. Oracle 11g
2. IBM DB2
3. MsSQL
4. FireBird
5. PostgreSql

Başka tavsiyesi olan varsa onu da değerlendiririz. Bu DB ler hakkında tavsiyete bulunabilecek var mı?

[Lost Soul]

Firebird seçneklerimde ilk sıradadır

Ayrıca SYSBase Advantage veri tabanı kullanabilirsin.
Tek kullanıcıda ücretsiz çok kullanıcı için ise ücret istiyor

[kefukar]

Onu belirtmemişim iyi hatırlattınız en az 10 kullanıcılı bir program...

[undefined]

Çok fazla kayıtta lazım olduğu söylenen partition desteği (maalesef) Firebirdde yok. Bunun dışında db büyümesinin firebird'de sorun olmadığı bilinen birşey.
FB'de gerçek olarak çok işlemcili çalışma v3'te gelecek. Eğer çok yüksek sayıda transaction aynı anda çalışmayacaksa ve sorun sadece DB büyüklüğündeyse FB'nin bu konuda problem çıkartacağını düşünmüyorum.

[mussimsek]

Sadece kayıt sayısını baz alarak bir seçim yaparsanız ters köşe olabilirsiniz. Daha önce veritabanı seçimiyle ilgili pek çok kez konuşuldu. Bir ara Doğan abi bu konuda baya bir yazmıştı.

Ayrıca Oracle ve M$ SQL bedava değildir. Ha Express sürümleri bedava diyeceksiniz, ama 2 GB veya 4 GB'a dayandığınız zaman ne olacak? Kaldıki 100 milyon kayıt ile 4-5 ayda dolduracağınız muhakkak.

Kolay gelsin.

[mrmarman]

- Proje hakkında bize söylediğin kadarını sana söyleselerdi hangi soruları sorardın ? Bizim de bu soruları soracağımızı düşünerek biraz daha detay vermeni beklerdim. Yıllık 100 milyon kayıt tek bir kriter değil. En az 10 kullanıcının bu kayıtları gireceği de.. Bu kadar veri ile vereceğimiz bilginin sana faydasından çok geri dönemeyeceğin zararı olacaktır.

- Doğru planlama ile basit MSAccess ile bile yapılabileceğini savunuyorum. Birbirinden bağımsız ama tamamlayıcı tablolar bir katalog dosyası içinde olduğu gibi, bunun bir büyük ölçeğini katalog dosyalarının birbiriyle ilişkisini kurmak imkansız değil. TCP bağlantısı aracılığıyla birbiriyle heberleşen modüller ile takviye edilmiş bir veritabanı projesi çok güçlü olabilir.

- Aman yanlış anlaşılmasın MSAccess kullanın demiyorum, teşbihte kusur olmasın sadece elinizde en pahalı veritabanı altyapısı dahi olsa başarısız olunabilir demek istiyorum.

- Buradaki fonksiyon kabaca

Kod: Tümünü seç

para = ( proje hakkında bilgi * proje için verilen zaman ) / ( Delphi bilgimiz * Veritabanı tecrübeniz )

eşitliğidir. Fonksiyonu şimdi uydurdum, hatalı olabilir ama özetle anlatmak istediğimi anltıyor sanırım.

Sadece kayıt sayısını baz alarak bir seçim yaparsanız ters köşe olabilirsiniz.

- Çok doğru bir tespit...

[kefukar]

Şöyle izah edeyim;

*En az 10 kullanıcı demiştim ama ortalama 50-60 kullanıcılı, uzaktan erişim ve sürekli veri girişi olacak

*Müşterilerle birebir ve anlık işlemler yapılacağından sürekli hareket olacak (transactionlar bol miktarda)

* Hale hazırda mükemmel modellenmiş FireBird DB üzerinde geliştirilecek bir proje. Lakin FB ile devam konusunda malum kriterlerden dolayı aklımıza soru işaretleri takılmıştı.
Şimdi şunu diyecekler mutlaka vardır. 'FB bu işi çok rahat halleder' ben de soruyorum bu boyutta bir projeyi FB ile yapmış ve yıllardır sorunsuz kullanımda olan biri var mı?

İlginize teşekkür ederim. Yorumlarınıza göre durumu değerlendireceğiz.
Kolay Gelsin.

NOT: Mustafa hocam yıllık 100 milyon kayıt demiştim.

[mrmarman]

- Projenin çerçevesini sormuştum ancak yine teknik cevaplamışsınız. Peki şöyle soralım.

100 milyon kaydın birinci kaydı ile 100 milyonuncu kaydını içine alacak bir sorguyu (tüm kayıtları listelemekten bahsetmiyorum, tüm kayıtlar her an ihtiyaç halinde mi diye soruyorum) her an çağırıyor musunuz ? yoksa sık olmayan aralıklarla istatistiki veri için mi bu dinamikte bir kayıt sayısına ihtiyaç var ?

Dönemsel kayıtlar olarak mı saklanacak yoksa tümleşik kayıtlar halinde mi ?

Log kayıtları halinde mi yoksa laboratuvar tarzı bir yerin hasta kayıtları tarzında tüm verileri halinde mi ?

Zaman aşımlı yani bir kişiye ait son 3 kayıt değerli gerisi arşiv şeklinde mi nitelik taşıyor ?

- vs. vs. sorular böyle uzar. Bu soruların cevapları sana gerekli yolu çizecektir. Daha önce dediğim gibi Firebird veya başka veritabanı ile daha önce istenen büyüklükte çözüm üretilebilir. Üretilen çözüm tek başına veritabanının gücü ile ölçülemez, programcının kurgusu basit veritabanlarını bile tahmin edeceğinden güçlü kılar. En hızlı veritabanında bile doğru planlama sağlanmazsa basit bir veritabanından da yavaş çalışacak veya çökecektir.

[kefukar]

Hocam şöyle anlatırsam sanırım tüm sorunlarınızın cevabını vermiş olacağım;

Program tabandan tavana kadar kurumsal firmaların tüm ihtiyaçlarını karşılayacak bir İŞ ZEKASI çözümü.

[sadettinpolat]

projeniz neden tek bir veritabanina bagli kaliyor ?
eger aklinizda bu tarz soru isaretleri varsa projeyi firebird, oracle, sql server, sybase, mysql veritabanlari ile calisabilecek sekilde yazarsiniz aklinizda hicbir soru isareti kalmaz. x db nin tikandigi yerde yapmaniz gereken ini dosyasindaki bir satiri degistirmek ve y db ile calisacak sekle getirmek.

[mrmarman]

Başarılar dilerim zihnin ve yolun açık olsun.

[ahmet_sinav]

iyi çalışmalar;
Öncelikle
viewtopic.php?t=19995&highlight=
linkini bir inceleyin derim.

[kefukar]

Teşekürler.