merhabalar, yanlış anlaşılmaması adına niyetimi en başta belirtmek istiyorum: söylediklerinizin doğruluk payı var Sezayi Bey fakat ben bazı kısmına katılmıyorum (lütfen eleştiriden ziyade faydalı bir tartışma olarak görün yazdıklarımı)
> Bu tür soruların hap çözümünü hemen vermek kolay değil. kronikleşen sorunu zamanla yada incelemelerle çözemezsiniz, 39000 kayıt için 16 yada 8 saniye gibi kabul edilemeyecek süreleri ancak radikal ya da sizin deyiminizle hap çözümü şeklinde çözebilirsiniz. >Sorgudan önce tablo yapılarını, veri tabanı modellemesine bakmak sorunun daha net anlaşılmasını sağlar. "sonuç bu ise bir yerlerde hata olmalı, şunlara bakın..." diyerek ben de buna işaret etmiştim. >Öncelikle Open Source yazılımlarda bu tür VT yapısı nasıl oluşturulmuş ,nasıl kodlar kullanılmış bakmakta fayda var ben tam da bu konuda bir açık kaynak muhasebe sistemi yazdım ve bir başkasının benim tablo yapılarımı inceleyerek kendi sistemindeki sorunları çözebileceğini pek sanmıyorum. veri yapılarını incelemek isterseniz : https://github.com/seyhanp/seyhan/tree/master/conf/evolutions evet bu projede de veri tablolarından başka birşey kullanılmadı >view, function, stored procedure ve trigger gibi veri tabanı araçlarının kullanmama kararı programcının tercihi olabilir. evet haklısınız fakat ben (nosql olanlar hariç) mysql, sql-server, oracle, pgsql... gibi yaygın olarak kullanılan veritabanlarının ilişkisel veritabanları olduğunu kabul ederek sadece verilerimi ilişkiler belirleyerek kullanmaya çalışıyorum bu yaklaşımım (günlük milyon hatta bazı durumlarda milyar istek durumunda) veritabanı darboğazlarını aşmamı sağladığı gibi istediğim zaman çok da zorlanmadan veritabanını değiştirmem sağlıyor (her ne kadar olmasa da, olabilme ihtimali var) sonuçta; trigger, stored procedure, view, function, standart sql de olmayan db ye has özel komutlar... gibi şeyler kesinlikle faydalı şeyler fakat her birinin getirdiği ek bir maliyet, yük ya da çekince / kısıtlama var. proje yapısı, kullanıcı sayısı, veri yoğunluğu, veritabanının değişime olan dirence, projenin open/closed source olup olmayacağı... gibi etkenler seçimlerimizi belirliyor. daha önce de yazdığım gibi; ben (ve çalıştığım projedeki insanlar) veritabanını sadece ilişkisel veriler için kullanıyoruz. trigger, stored procedure, view, function, standart sql de olmayan db ye has özel komutlar... gibi şeyleri kullanmak yanlıştır, aman ha kullanmayın demiyorum. bana göre sıkıntılı şeyler ve baş ağrıtabilir diyorum sadece. 2017-10-23 8:44 GMT+03:00 SEZAYİ BUĞDAYCI <sbugda...@etimaden.gov.tr>: > - Bu tür soruların hap çözümünü hemen vermek kolay değil. Sorgudan önce > tablo yapılarını, veri tabanı modellemesine bakmak sorunun daha net > anlaşılmasını sağlar. > Optimum çözümler onun üzerinden düşünülür. Burada daha çok genel olası > şeyler önerilebilir. Öncelikle Open Source yazılımlarda bu tür VT yapısı > nasıl oluşturulmuş , > nasıl kodlar kullanılmış bakmakta fayda var. (İncelendiğini sanıyorum) > - view, function, stored procedure ve trigger gibi veri tabanı > araçlarının kullanmama kararı programcının tercihi olabilir. Ancak doğru > yerinde doğru yapılandırılması, > Programcıyı birçok kod yazmaktan kurtarır ve sağlam çalışır. Yanlış > yapılanması ise VT yi germesine neden olabilir. Örneğin kayılardaki > işlemlerin loglarını trigger ile yapmak en iyisidir. > Trigger ile stok hesaplamak (Yine VT tasarımınıza bağlı olarak) doğru > seçim olmaz. > > > İyi çalışmalar. > > > > > ------------------------------ > *Kimden: *"M.Dumlupinar" <mdumlupi...@gmail.com> > *Kime: *"Özgür yazılımlarla çeşitli dillerde yazılım geliştirme" < > linux-programlama@liste.linux.org.tr> > *Gönderilenler: *22 Ekim Pazar 2017 18:41:56 > *Konu: *[Linux-programlama] Re: ön muhasebe stok hesaplama > > benim dikkatimi ceken birsey var; > normalde yazilim tarafinin yapmasi gereken seyleri neden db tarafina > yaptirmissiniz. bu tur seyler faydadan cok zarar getirir. > > veritabanlari darbogazdir, calisma mantiklari basit kume teorilerine > dayanir yani kompleks veri tipleri gibi islemler de sikintiya sebep olur. > > standart sql disinda birseyler yazmaya basliyorsaniz bir yerlerde hata > vardi. bence bu tur yerleri duzeltmeden sorgularinizi elden gecirmeyin. > > performans adina, benim bir onceki calistigim yerde veritabaninda veriden > baska birsey (view, function, stored procedure ve trigger...) buldurulmazdi. > > suanki isyerimde durum biraz daha sıkı; hiçbir sekilde join dahi > kullanamiyoruz :) > > > 22 Ekim 2017 Pazar tarihinde, SEZAYİ BUĞDAYCI <sbugda...@etimaden.gov.tr> > yazdı: > >> Sorguda çok alt sorgu var, Dolayısı ile her alt sorgu zamanı artırdığı >> kanaatindeyim. Alt sorgular yerine view( MySQL de kullanılıyor mu >> bilmiyorum) kullanılması zamanı azaltabilir. >> >> İyi çalışmalar. >> >> ------------------------------ >> *Kimden: *"ibrahim" <ibrahim...@gmail.com> >> *Kime: *"Özgür yazılımlarla çeşitli dillerde yazılım geliştirme" < >> linux-programlama@liste.linux.org.tr> >> *Gönderilenler: *20 Ekim Cuma 2017 23:18:49 >> *Konu: *[Linux-programlama] ön muhasebe stok hesaplama >> >> Merhaba JAVA+MySQL(maria db) li bir ön muhasebe yazılımı üzerinde >> çalışıyorum.stok miktarını aşağıdaki sorgu ile hesaplıyorum ve sorguyu >> çalıştırdığımda sorgu süresi 16 sn alıyor. acaba sorgu süresi normal mi ? >> sorguda hata mı yapıyorum ? >> >> SELECT products_id as ID,prod_name as 'Ürün Adı',IFNULL((SELECT >>> sum(urun_adet) FROM `ktgcari_000_fatura_xref` where >>> product_id=ktgcari_000_stok.products_id and (type=1 or >>> type=4)),0)-IFNULL((SELECT sum(urun_adet) FROM `ktgcari_000_fatura_xref` >>> where product_id=ktgcari_000_stok.products_id and (type=2 or >>> type=5)),0)+IFNULL((SELECT sum(miktar) FROM ktgcari_000_ssayim where >>> urun_id=ktgcari_000_stok.products_id),0) as 'Stok' FROM >>> ktgcari_000_stok LIMIT 0,1000 >> >> >> (gelen fatura toplamı+gelen irsaliye toplamı)-(giden fatura toplamı+giden >> irsaliye toplamı)+(sayım fişi toplamı) >> >> Veritabanı Bilgileri: >> stok kartı sayısı: 39000 >> fatura sayısı: 545 >> fatura içeriği tablosu kayıt sayısı: 1800 >> sayım fişi sayısı: 942 >> veritabanı büyüklüğü: 5 MB >> >> -- >> -- >> Saygılarımla, >> İbrahim Halil >> >> _______________________________________________ >> Linux-programlama mailing list >> Linux-programlama@liste.linux.org.tr >> https://liste.linux.org.tr/mailman/listinfo/linux-programlama >> Liste kurallari: http://liste.linux.org.tr/kurallar.php >> >> -- >> *SEZAYİ BUĞDAYCI* >> *Eti Maden İşletmeleri Genel Müd.* >> Yön. Bil. Sis. Dai. Başkanı >> >> Ayvalı Mah. Halil Sezai Erkut Cad. >> Afra Sk. No 1/A 06010 Etlik-Keçiören/ANKARA >> Tel: +90(312) 294 21 52 <+90%20312%20294%2021%2052>, (530) 693 34 36 >> e-posta: sbugda...@etimaden.gov.tr >> > > > -- > İyi çalışmalar... > > Mustafa DUMLUPINAR > https://github.com/seyhanp > > > _______________________________________________ > Linux-programlama mailing list > Linux-programlama@liste.linux.org.tr > https://liste.linux.org.tr/mailman/listinfo/linux-programlama > Liste kurallari: http://liste.linux.org.tr/kurallar.php > > -- > *SEZAYİ BUĞDAYCI* > *Eti Maden İşletmeleri Genel Müd.* > Yön. Bil. Sis. Dai. Başkanı > > Ayvalı Mah. Halil Sezai Erkut Cad. > Afra Sk. No 1/A 06010 Etlik-Keçiören/ANKARA > Tel: +90(312) 294 21 52 <+90%20312%20294%2021%2052>, (530) 693 34 36 > e-posta: sbugda...@etimaden.gov.tr > > _______________________________________________ > Linux-programlama mailing list > Linux-programlama@liste.linux.org.tr > https://liste.linux.org.tr/mailman/listinfo/linux-programlama > Liste kurallari: http://liste.linux.org.tr/kurallar.php > > -- İyi çalışmalar... Mustafa DUMLUPINAR https://github.com/seyhanp
_______________________________________________ Linux-programlama mailing list Linux-programlama@liste.linux.org.tr https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
