40 000 in üzerindeki öğrenciye hangi veritabanı?
40 000 in üzerindeki öğrenciye hangi veritabanı?
Arkadaşlar Merhaba
40 000 in üzerindeki öğrencinin kayıt ve not bilgilerine erişilip üzerinde işlem yapılacak bir otomasyon projesinde veritabanı olarak (Linux Üzerinde ) postgresql veya firebird 1.5 gibi ücretsiz veritabanlarını kullanmak istersek
1- Bu ücretsiz veritabanlarını performans , sağlamlık ve güvenlik açısından önerirmisiniz ?
2- Önerirseniz hangisini tercih edersiniz.
3- Siz olsaydınız bu ücretsiz veritabanları yerine başımın ağrımaması için hiç olmazsa MsSql Server ı (veya oracle) tercih ederdim dermiydiniz.?
Cevabınızı sabırsızlıkla bekliyorum
kolay gelsin
40 000 in üzerindeki öğrencinin kayıt ve not bilgilerine erişilip üzerinde işlem yapılacak bir otomasyon projesinde veritabanı olarak (Linux Üzerinde ) postgresql veya firebird 1.5 gibi ücretsiz veritabanlarını kullanmak istersek
1- Bu ücretsiz veritabanlarını performans , sağlamlık ve güvenlik açısından önerirmisiniz ?
2- Önerirseniz hangisini tercih edersiniz.
3- Siz olsaydınız bu ücretsiz veritabanları yerine başımın ağrımaması için hiç olmazsa MsSql Server ı (veya oracle) tercih ederdim dermiydiniz.?
Cevabınızı sabırsızlıkla bekliyorum
kolay gelsin
madem linux diyorsun bence MySQL de oldukça iyi bir çözüm olabililr. ama 4.0 ve üzeri
Volkan KAMADAN
www.polisoft.com.tr
www.polisoft.com.tr
Selr,
Linux üzerinde eğer mümkünse Oracle (Ticari bakımdan destek bulabilmek için) ama ücret ödemek istemiyorum derseniz elbetteki Firebird 1.5. Oracle açısından olaya baktığınızda lisans ücretleri nedeniyle pahalıya gelebilir. Ama Firebird'de böyle bir durum söz konusu değil. Herşey serbest
MySQL'in galiba Trigger ve Stored Procedure gibi bir takım eksikleri var diye biliyorum (Eğer bir değişiklik olmadıysa) bu sebeple Firebird tercih nedeni olabilir. Zira bu tarz şeylerde Stored Procedure, Trigger gibi RDBMS'lere özgü yapılar işlerinizi kolaylaştırıp rahatlatır. Aksi takdirde koda çok yüklenmeniz gerekecektir.
Linux üzerinde eğer mümkünse Oracle (Ticari bakımdan destek bulabilmek için) ama ücret ödemek istemiyorum derseniz elbetteki Firebird 1.5. Oracle açısından olaya baktığınızda lisans ücretleri nedeniyle pahalıya gelebilir. Ama Firebird'de böyle bir durum söz konusu değil. Herşey serbest

MySQL'in galiba Trigger ve Stored Procedure gibi bir takım eksikleri var diye biliyorum (Eğer bir değişiklik olmadıysa) bu sebeple Firebird tercih nedeni olabilir. Zira bu tarz şeylerde Stored Procedure, Trigger gibi RDBMS'lere özgü yapılar işlerinizi kolaylaştırıp rahatlatır. Aksi takdirde koda çok yüklenmeniz gerekecektir.
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
S.A
Sevgili dostlar..
Sevgili Kuri_TLJ kardeşş...Jedi larin en yakışıklısı..
Oracle da ust duzey bir arkadaşım standa gelmişti.Bursa fuarında kısmet biraz sohbet ettik artık fiyatların eskisi gibi kesinlikle pahalı olmadığını ve baya bi aşağı çektiklerini soledi..
Sebepse ortada zaten..Mysql PostgreSql FireBird gibi bedava ve iyi hizmet goren veritabanlarının piyasada sağlam bir yer edinmesi haliyle adamların canını sıkıyor..
Stored procedure ler 5.0 alfa ile artık varlar..Search yapacak olursan bir ornekte vermistim..Ama triggerlar ki benim hasretle beklediğim hatta hazırlık olsun diye gidipte oracle dokumanlarından nasıl yazıldığını ogrenip Mysql e eklenince ufak tefek syntax değişiklikleriyle sisteme hemen adapte edeceğimi düşündüğüm şeker şeyler...ONLAR ne yazık ki yok ..Ama 40000 için 1 2 sn beklerim ve app code abanırım diyorsan o zaman paşasın ..
Bence bekle bekleyen derviş olayı yani..
Ayrıca bildiğim kadarıyla Oracle hala ve hala dünya pazarının % 53 unu elinde tutuyor..
Ama ne diyeyim SqlPlus ı yeter be abi..
Adama heeeeee desem hödö dicekmiş gibi geliyor..Herşey düşünülmüş...
Sevgili kahinimiz
En derin sevgi ve Saygılar...
Ha bu arada ben MySql derim şüphesiz..Ben 1 milyon kayıtta çalışıyorum..
Tahmin edin..40 000 bizim sistemler için çerez..
Ama hep derim ya aslında veri tabanının suçu yok bence bazı durumlasrda programcinin yanlış algoritmalari veya algoritma define eksiklikleri haliyle programa yavaşlık olarak yansıyor..

Kalın Sağlıcakla...
KARDEŞLERİM... YAŞASIN DELPHİ KARDEŞLİĞİ
Sevgili dostlar..
Sevgili Kuri_TLJ kardeşş...Jedi larin en yakışıklısı..

Oracle da ust duzey bir arkadaşım standa gelmişti.Bursa fuarında kısmet biraz sohbet ettik artık fiyatların eskisi gibi kesinlikle pahalı olmadığını ve baya bi aşağı çektiklerini soledi..
Sebepse ortada zaten..Mysql PostgreSql FireBird gibi bedava ve iyi hizmet goren veritabanlarının piyasada sağlam bir yer edinmesi haliyle adamların canını sıkıyor..
Stored procedure ler 5.0 alfa ile artık varlar..Search yapacak olursan bir ornekte vermistim..Ama triggerlar ki benim hasretle beklediğim hatta hazırlık olsun diye gidipte oracle dokumanlarından nasıl yazıldığını ogrenip Mysql e eklenince ufak tefek syntax değişiklikleriyle sisteme hemen adapte edeceğimi düşündüğüm şeker şeyler...ONLAR ne yazık ki yok ..Ama 40000 için 1 2 sn beklerim ve app code abanırım diyorsan o zaman paşasın ..


Ayrıca bildiğim kadarıyla Oracle hala ve hala dünya pazarının % 53 unu elinde tutuyor..
Ama ne diyeyim SqlPlus ı yeter be abi..
Adama heeeeee desem hödö dicekmiş gibi geliyor..Herşey düşünülmüş...
Sevgili kahinimiz

En derin sevgi ve Saygılar...
Ha bu arada ben MySql derim şüphesiz..Ben 1 milyon kayıtta çalışıyorum..
Tahmin edin..40 000 bizim sistemler için çerez..
Ama hep derim ya aslında veri tabanının suçu yok bence bazı durumlasrda programcinin yanlış algoritmalari veya algoritma define eksiklikleri haliyle programa yavaşlık olarak yansıyor..

Kalın Sağlıcakla...
KARDEŞLERİM... YAŞASIN DELPHİ KARDEŞLİĞİ

c#



-
- Üye
- Mesajlar: 20
- Kayıt: 30 Nis 2004 04:54
- Konum: Lüleburgaz / KIRKLARELİ
- İletişim:
40.000 kayıt üzeri
interbase (yada firebird) kesin çözüm bence.
market programı yazdım, en o civarda kayıt var iki kullanıcılı
gayet iyi işliyor sistem, problem yok
market programı yazdım, en o civarda kayıt var iki kullanıcılı
gayet iyi işliyor sistem, problem yok
S.A
Ayrıca Volkan KAMADAN 'a..
Neden 4.x ve ustü ? Neye dayanarak söylüyorsunuz ? Test ettiniz mi ?
Ayrıca Volkan KAMADAN 'a..
Neden 4.x ve ustü ? Neye dayanarak söylüyorsunuz ? Test ettiniz mi ?
En son NetZero tarafından 24 Ağu 2004 01:27 tarihinde düzenlendi, toplamda 1 kere düzenlendi.
c#



-
- Kıdemli Üye
- Mesajlar: 395
- Kayıt: 22 Tem 2004 09:15
- Konum: İzmir
- İletişim:
Selam,
Bir database seçerken sadece "40.000 kaydı yapabilir mi ?" sorusuna cevap olabilecek birşeylerle yaklaşmak yanlış olacaktır diye düşünüyorum. Öncelikle kayıt sayısı en kötü db lerde bile milyon kayıtlara kadar ulaşabilir. Bir ihtiyaç listesi yapalım; (İ: ihtiyaç, C: cevaplayabilen veritabanları, Ve Diğerleri: Benim bilmediklerim yada aklıma gelmeyenler)
İ. Bir veritabanı lazım.
C. MS Access, Paradox, MySQL, Oracle, MS SQL Server, FireBird, Progress, ve diğerleri.
İ. Yüksek duraylılık sahibi olmalı.
C. MS Access, MySQL, Oracle, MS SQL Server, FireBird, Progress, ve diğerleri.
İ. Client/Server çalışmalı (performans için)
C. MySQL, Oracle, MS SQL Server, FireBird, Progress, PostgreSQL ve diğerleri
İ. Yerleşik replikasyon desteği sağlamalı
Oracle, MS SQL Server, FireBird, Progress, PostgreSQL ve diğerleri
İ. Yerleşik High Availibility Çözümleri sunmalı (sistemin herhangi bir an duraksaması istenmiyor, roll forwarding, yada sby db gibi)
C: Oracle, MS SQL Server, Progress ve diğerleri
İ. Aşırı yükleme altında load balancing yapabilmesi yada Cluster çalışabilmesi
C: Oracle, MS SQL Server ve diğerleri
İ. Failover durumunda 1 record bile kaybetmeye tahammülüm yok
C. Oracle ve diğerleri
......
Yani ilk başta elimizdeki seçenekleri düşünürsek, ihtiyaçları iyi hesaplamak gerekir. Yukardan aşağı ihtiyaçlar belirlenmeli ve tüm veritabanlarını kapsayan küme bu şekilde elenmelidir. Örneğin yukardaki modelin tersine bir ticari paket yazdınız ve eğer plug-n-play bir setup hazırlayacaksanız bu durumda Oracle yada Progress kullanamazsınız.
Kalın sağlıcakla,
Bir database seçerken sadece "40.000 kaydı yapabilir mi ?" sorusuna cevap olabilecek birşeylerle yaklaşmak yanlış olacaktır diye düşünüyorum. Öncelikle kayıt sayısı en kötü db lerde bile milyon kayıtlara kadar ulaşabilir. Bir ihtiyaç listesi yapalım; (İ: ihtiyaç, C: cevaplayabilen veritabanları, Ve Diğerleri: Benim bilmediklerim yada aklıma gelmeyenler)
İ. Bir veritabanı lazım.
C. MS Access, Paradox, MySQL, Oracle, MS SQL Server, FireBird, Progress, ve diğerleri.
İ. Yüksek duraylılık sahibi olmalı.
C. MS Access, MySQL, Oracle, MS SQL Server, FireBird, Progress, ve diğerleri.
İ. Client/Server çalışmalı (performans için)
C. MySQL, Oracle, MS SQL Server, FireBird, Progress, PostgreSQL ve diğerleri
İ. Yerleşik replikasyon desteği sağlamalı
Oracle, MS SQL Server, FireBird, Progress, PostgreSQL ve diğerleri
İ. Yerleşik High Availibility Çözümleri sunmalı (sistemin herhangi bir an duraksaması istenmiyor, roll forwarding, yada sby db gibi)
C: Oracle, MS SQL Server, Progress ve diğerleri
İ. Aşırı yükleme altında load balancing yapabilmesi yada Cluster çalışabilmesi
C: Oracle, MS SQL Server ve diğerleri
İ. Failover durumunda 1 record bile kaybetmeye tahammülüm yok
C. Oracle ve diğerleri
......
Yani ilk başta elimizdeki seçenekleri düşünürsek, ihtiyaçları iyi hesaplamak gerekir. Yukardan aşağı ihtiyaçlar belirlenmeli ve tüm veritabanlarını kapsayan küme bu şekilde elenmelidir. Örneğin yukardaki modelin tersine bir ticari paket yazdınız ve eğer plug-n-play bir setup hazırlayacaksanız bu durumda Oracle yada Progress kullanamazsınız.
Kalın sağlıcakla,
Doğan Zorlu, İzmir
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
Sayın NetZero,
MySQL 4.x ve üstü deme nededim,
Transaction desteğinin MySQl ye 4.x ve üzeri versiyonlar için sağlanmış olmasıdır.
Ayrıca uzun süredir mySQL InnoDB yi verimli bir şekilde kullanıyorum 4.x öncesinde sadece MyISAM tablolarını kullanabildiğimiz için çabuk bozulmalar ve onarımlar sırasında kaybolan kayıtlar nedeniyle veri bütünlüğünün korunamaması gibi sorunlarla karşılaşılabiiyordu.
Bu sebepten Transaction desteiği sağlana InnoDB tablolarını sunan 4.x ve üzeri versiyonları öneririm eğerki MySQL kullanacağım diyorsan.
Başarılar.
MySQL 4.x ve üstü deme nededim,
Transaction desteğinin MySQl ye 4.x ve üzeri versiyonlar için sağlanmış olmasıdır.
Ayrıca uzun süredir mySQL InnoDB yi verimli bir şekilde kullanıyorum 4.x öncesinde sadece MyISAM tablolarını kullanabildiğimiz için çabuk bozulmalar ve onarımlar sırasında kaybolan kayıtlar nedeniyle veri bütünlüğünün korunamaması gibi sorunlarla karşılaşılabiiyordu.
Bu sebepten Transaction desteiği sağlana InnoDB tablolarını sunan 4.x ve üzeri versiyonları öneririm eğerki MySQL kullanacağım diyorsan.
Başarılar.
Volkan KAMADAN
www.polisoft.com.tr
www.polisoft.com.tr