Merhaba, On Jul 27 10:32, Seref Arikan wrote: > Nacizane bir yorum da ben yapayım; veritabanı içerisinde başka hiç bir > çaremin kalmadığı durumlar haricinde asla mantık içeren bir kod > bulunmasına izin vermiyorum. Tabi ki yazılım gibi bir alanda genelleme > yapmak çok yanlış, eminim buna mecbur kalınan bir çok notka da vardır. > Özellikle çok büyük miktarda veri söz konusu olduğu zaman firmadaki > oracle üstadı arkadaşlara işi devredip, onların çözüme müdahale etmesine > izin veriyorum. Ama %99 oranında çok katmanlı kurumsal yazılımlar > geliştirilen bir firmada çalışan birisi olarak, yine çok büyük yüzde ile > db seviyesinde bu tarz teknolojileri kullanmamaktan yanayız. Nedenlerine > uzun uzun girmek istemiyorum, bambaşka bir tartışma konusu; ama temel > olarak java ve db bağımsızlığına yaptığımız yatırımın bize iş modeli ve > dolayısı ile stratejik avantaj olarak çok ciddi geri dönüşleri var. Yani > DB den bağımsız olmak zorunda olan multi milyon dolarlık bir yatırım söz > konusu, ve ben bazı durumlarda işi ne kadar kolaylaştırsa da bahsi geçen > türde çözümleri kullanamam. > Ha tam bu tarz bir şeye ne zaman ihtiyacım oldu? Bir oracle forms > uygulamasının web servislerini çağırması gerektiğinde, web servisi de > yapı olarak ssl falan kullanan bir parça karmaşık bir şey olduğu için > oracle db içindeki jvm ile web servisi çağıran bir java programcığı > yazdım. Tabi orada da bir sürü sorun çıktı , ama sonuç olarak kişisel > olarak çok faydalı bir deneyim olabileceğine katılsam da, oldukça > uçlarda bir proje olur diye düşünmekeyim.
Kitleleri arkanızda sürükleyecek bir reklam potansiyelinizin olmadığı her proje için doğru değil mi bu? Eğer Bill Gates öz amcam olsaydı, eminim .NET, Lisp dialektlerini öntanımlı olarak desteklerdi. > Tabi gezegen geniş; mutlaka > kullanacak birisi de çıkar, ama harcanacak eforu bir iki katman yukarı > çekerek daha geniş kitlelere hitap eden, ve kullanılması daha yaygın > olacak bir proje tercih edilebilir. O da paradan puldan ziyade, > kullanıcı kitleri oluşan bir proje kolay kolay ölmez şeklinde bir > düşünceden dolayı Bu konuya çok fazla girmek istemiyorum (liste konusunda dışında epey bir şeyler yazdım bu aralar) ve taşınabilirlik kaygınızı anlıyorum. Bu PostgreSQL listesinde de sık sık tartışılıyor, örneğin, JDBC sürücüsü kullanarak standarta uygun taşınabilir bir kod mu yazalım, yoksa standartın dışına çıkarak PostgreSQL'in gerçekten tüm özelliklerinden istifade mi edelim? Bu soruya genelde verilen cevap basittir, zaten büyük bir yazılım geliştiriyorsanız (veritabanının devasa olmasına gerek yok) kendi standartlarınızı kendiniz koyarsınız. Bizim yazılımımız sadece (atıyorum) PostgreSQL ile çalışıyor dersiniz ve konu kapanır, o kadar. Kimse böyle framework mantığı ile çalışacak bir uygulamanın taşınabilirliğini sorgulamaz. Büyük projelerde taşınabilirlik ile kazanacağınız müşteriyi (şahsi fikrim) emin olun performans ve esneklik ile geri ödersiniz. Çoğu yazılım firmasında da taşınabilirliğin sadece reklam broşürlerinde kaldığı ap ayrı bir mevzu. Yazılım Java ile yazılmıştır, kodu da gerçekten taşınabilirdir ama yıllardır Microsoft Windows Server'dan başka hiçbir yerde çalıştırılmamıştır. İşte böyle bir durumda işin taşınabilirliği proof-of-concept ve kaybedilen esneklik, başarımdan ibarettir. Konuya dönecek olursam (nihayet) piyasada hiçbir standart (ve taşınabilir) prosedürel dil olmadığı halde, veritabanına gömülü prosedür kullanımının bu kadar büyük bir kullanıcı kitlesine sahip olması, yukarıda bahsi geçen riskin PL/lisp için de çok bir şey ifade etmediğinin ayrı bir ispatı olarak görülebilir. Tabi bunlar benim fikirlerim. Pazarın vahşi rekabeti herkese sözlerini geri yedirebilir. :-) İyi çalışmalar. _______________________________________________ cs-lisp mailing list [email protected] http://church.cs.bilgi.edu.tr/lcg http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
