On Jul 27 05:43, Emre Sevinç wrote:
> Veritabani isleri ile yogun olarak ugrasiyorum ama MS teknolojileri
> ile. Yillardir MS SQL Server kullaniyorum. MS SQL Server'da
> PostgreSQL'e benzer bir durum olusmaya basladi. Simdiye dek sadece
> T-SQL denen bir dil ile stored procedure yazilabilirken artik yavas
> yavas C# dili ile yazma destegi de geliyor.
>
> Kendi durumumu düsünüyorum, mesela C# ile stored procedure yazmak ister
> miydim, bu ne avantaj saglardi?
Bence veritabanında yapılacak işi istemci uygulaması üzerinde değil de
veritabanında yapmak kesinlikle çok daha mantıklı ve kolay bir şey.
Bunun istemci tarafında daha az kod yazma maliyeti getireceğinden,
başarım artışı sağlayacağından falan ise hiç bahsetmiyorum. Bir de insan
kendi kullandığı programlama dilini yine veritabanında prosedür yazmak
için de kullanabiliyorsa bu gerçekten çok büyük bir kolaylık ve esneklik
olur.
> Birincisi homojenlik: Uygulamami C# ile yaziyorum. Uygulamamin
> kullanacagi veritabani kodunu da C# ile yazmaya baslarsam zirt pirt
> farkli mantaliteler ve sözdizimleri arasinda gidip gelmem gerekmez.
+1
> Ikincisi: Framework, yani .NET ve C# ile gelen binlerce "class library".
> String islemlerinden tutun XML konusuna ve baska pek cok seye dair her
> zaman elimin altinda olan islevselligin artik veritabaninin icinde de
> ayni sekilde kullaniliyor olmasi güzel bir nokta olur.
Bir başka deyişle, her seferinde tekerleği yeniden icat etmek yerine,
varolan fabrikalardan kullanımınıza en uygun tekerlek siparişini
verebilirsiniz. Yani buna da +1.
> Ucüncüsü: Nesneye yönelik programlama mantalitesini ve algoritmik
> karmasikligi yine daha alisik oldugum bir dille ifade edebilme gücü.
Ben işte kesinlikle bu noktada Lisp'in farklı olacağına inanıyorum.
Bu ister PostgreSQL olsun, isterse DB2, Oracle. Farklı programlama
dilleri ile stored procedure yazma imkanı sunan neredeyse bütün
veritabanları imperatif programlama dilleri kullanmışlar. Çok kaba bir
örnek vermek gerekirse: PL/perl ile yaptığınız neyi PL/python ile
yapamazsınız? Hangisinde var olan bir kütüphane diğerinde yok? İkisinin
de sınırları birbirinden çok uzak değil gibi görünüyor değil mi? Ama
ikisinin de epey büyük bir kullanıcı kitlesi mevcut. İnsanlar bir dili
tercih ettiklerinde onun bu iş için daha uygun olduğuna karar
kılıyorlar ki o yönde devam edip gene aynı dili veritabanında da
kullanmak istiyorlar. Ben de bu düşünceden çok zuzağa gitmiyorum
zaten, aynı yöntem bence PL/lisp (ya da PL/scheme) içinde yol açıcı
bir etki gösterebilir.
> Hangi uygulamalarda kullanilacak ne tür prosedürlerde Lisp'in ifade gücüne
> ihtiyac duyulacak?
Unutmadan, benim özellikle Lisp söz dizimini kullanmamın asıl nedeni şu:
[Bu yazdıklarım PostgreSQL internals için doğru, fakat teorik olarak
benim bildiğim neredeyse diğer bütün veritabanları da aynı yöntemi
kullanıyor.] Stored procedure kullanarak öyle bir uygulama yazdığınızı
düşünün ki, çeşitli tablolardan topladığı sonuçları, sanki bir tabloyu
sorgulamışsınızcasına size döndürüyor. Yani bir nevi
SELECT * FROM istedigim_satirlar(ozellikleri);
şeklinde düşünün. Peki bir veritabanı executor'ı nasıl satır döndürür?
Eldeki plan düğümlerini her bir seferinde rekürsif olarak tek bir satır
döndürecek şekilde çağırır. (Sort gibi benzer işlemlerde, alt
düğümlerin tüm satırlarına ihtiyaç duyulduğunu es geçiyorum.) Bunu
kabaca şu şekilde izah edebilirim.
(Sort :key col0
(MergeJoin :condition (= col1 col2)
(IndexScan tbl0
(Filter :condition (< col0 '2006-07-27'::timestamp))
(SeqScan tbl1)))
Şematik olarak Lisp sözdizimine benzerliği sadece benim hayal gücümden
mi ibaret? Hiç sanmıyorum:
EXPLAIN
SELECT T1.oid
FROM pg_class AS T1
INNER JOIN information_schema.tables AS T2
ON (T1.relname = T2.table_name);
Hash Join (cost=8.59..29.83 rows=92 width=4)
Hash Cond: (c.relnamespace = nc.oid)
-> Hash Join (cost=7.53..27.39 rows=92 width=8)
Hash Cond: (((c.relname)::...)
-> Seq Scan on pg_class c (cost=0.00...)
Filter: ((relkind = ANY ('{r,v}'::"char"[])) AND ...)
-> Hash (cost=7.02..7.02 rows=202 width=68)
-> Seq Scan on pg_class t1 (cost=0.00..7.02 ...)
-> Hash (cost=1.05..1.05 rows=5 width=4)
-> Seq Scan on pg_namespace nc (cost=0.00..1.05 rows=5 ...)
Yani demek istediğim o ki, Lisp söz dizimi tarafından sağlanan
fonksiyonel programlama nimetlerine (ister tail recursion olsun,
isterse ağaç yapılarında sağladığı kolaylık olsun) veritabanı camiası
çok da sessiz kalmayacaktır. Ki bugüne kadar bunun yapılmamış olmasını,
Lisp camiasına yapılan gözü kapalı eleştirilere benzetiyorum.
> Yine ayni noktaya takiliyoruz: Bu muazzam güce su anda PostgreSQL
> kullananlarin kacta kaci ihtiyac duyar. Diyelim ki bir kismi duyar
> pekiyi zaten tasarlamis olduklari bir sistemi oturup bu yeni dili
> kullanarak yazarlar mi? Maliyeti yüksek.
Lisp kullanarak yazdığınız bir dataware house'da (ki bence Bülent Bey
isterse bu konuda bize epey bir örnek verebilir) veritabanı üzerinde yer
alan prosedürlerinizi PL/perl mü, yoksa PL/pgSQL ile mi yazmak
istersiniz?
> Sanirim yukarida kast edilen yani "prosedürel" derken, "stored
> procedure" mi kast ediliyor?
Evet. (Bu konuya hiç girmemek lazım. -hackers listesinde harıl harıl
dökümantasyonda yer alan function ve stored procedure deyimlerinin
birbiri yerine kullanımı tartışılıyor.)
> Eger öyle ise benim daha önce yazdiklarim akla geliyor. O kadar karmasik
> bir sey degilse o zaman basa cikilmasi gereken bir karmasiklik yok.
Burada beni yanlış anladınızı, ben veritabanı prosedürleri normal
uygulamalar kadar karmış değil derken şunu kast etmiştim: Örnek ile
açıklayacak olursam, elbette bir muhasebe programının istemci tarafından
uygulama kodu, veritabanında yer alan koda kıyasla kat be kat büyük ve
daha karmaşıktır.
Ama dillerin birbiri üzerine olan artıları da unutulmamlı. Basit bir
misal olarak, PL/pgSQL ile yaklaşık 20 satırda yazdığınız bir kodu
PL/perl ile tek bir satırda yazabiliyorsunuz. Ve PL/perl dengi gayet de
hızlı çalışıyor.
> Eger bu yoksa, neyi cözmeye calisiyoruz sorusu tekrar gündeme gelir.
Ben daha önceden çözülmemiş bir sorunu çözmekten öte, var olan çözüme
optimize etmeye çalışıyorum. Programlama işi neredeyse 1 yüzyıl önce
çözülmüştü, ama bugün hala programlama dilleri geliştiriliyor? Siz
hala annenizin Assembly'sini mi kullanıyorsunuz yoksa?
> Bu önemli cünkü gelistirilen seyin kullanimini etkiler. Eger pek cok
> veritabani gelistiricisi bunu kullanmazsa o zaman dogru dürüst
> geribesleme gelmez. Yapilabildigi gösterilmis olur ama o sekilde
> kalir. "Proof of concept" kabilinden bir sey olur yani. Istenen bu
> mudur? Yoksa daha fazlasi mi?
Bence popüler kültürü takip etmediğiniz sürece (ki Lisp gibi epey sivri
bir kullanıcı kitlesine sahip bir programlama dilini düşünecek olursak)
bu risk sizi her daim rahat bırakmayacaktır.
> Yukarida "framework"e deginmistim. Bilmedigim icin sorayim, ben simdi
> PostgreSQL stored procedure'larini Perl ile yazacak olsam, istedigim
> CPAN modülünü bunun icinden kullanabiliyor muyum?
Perl debugger ve profiler'larını bile kullanabiliyorsunuz. ;-)
> Benzer sey secilecek Lisp icin de söylenebilir. Bu implement
> edildiginde o dilin cevresini olusturan islev kütüphaneleri de bir
> parcasi olacak mi? Bu durumda Scheme mi yoksa CL mi?
Bu konuda hala kimse öneride bulunmadı. Tekrar hatırlatmak isterim, çoğu
sistemde öncende kurulu olma olasılığı yüksek bir Lips derleiyicisi
bence çok daha büyük bir seçiciliğe sahip. Gerçi, PL/lisp'i kullanacak
birinin kendi Lisp implementasyonunu tercih etmek istemesi de oldukça
muhtemeldir. Ama dediğim gibi, kullanacak derleyiciye önceden karar
verilmeli. Ona göre trigger, SPI vb. destekler verilecek.
> Performansi nasil? PostgreSQL icine gömüldügünde diger dillere göre
> performansi nasil olur?
Hepsinin gayet yüksek. Hatta neredeyse bütün PostgreSQL PL'leri
veritabanı backend'ine izin verilen shared memory içinde kendi
geliştirdikleri önbellek (cache) mekanizmalarını kullanarak epey bir de
hız artışı sağlıyorlar.
> Bunu etkileyen faktörler neler olur?
Cache mekanizması oldukça önemli bir olgu. Ama şuan için birinci planda
değil bence.
İ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
