Veri Tabanı Senaryosu
Veri Tabanı Senaryosu
Bir stok programında, birden fazla firma takip edilmek isteniyorsa herbir firma kayıtları ayrı veritabanındamı tutulmalı yoksa aynı veri tabanı içindemi tutulmalı? aynı veri tabanında tutulursa sorgulamalarda, kayıt sayısı artacağından gecikme olmazmı? yada aynı veritabanında her firma için ayrı tablomu oluşturmak gerekir.
Stok kayıtlarının yıl sonundaki devir işlemi nasıl yapılmalı? Yine yıla göre ayrı tablomu oluşturlmalı?
Daha önceleri herbir firma için bir klasör oluşturuyordum ve her firma klasörünün altında çalışılan yıl için bir klasör oluşturuyordum. Dataları bu klasörlerin içinde saklıyordum. Yıl sonundaki devir işleminde de yeni yılın klasöründe dosyaları oluşturup, kayıtları "geçen yıldan devir" diye tek bir kayıtta gelecek yıla devrini yapıyordum.
Bu işelmi Interbase/firebird'de nasıl yapmam gerektiği konusunda fikir verirseniz memnun olurum.
İyi çalışmalar
Stok kayıtlarının yıl sonundaki devir işlemi nasıl yapılmalı? Yine yıla göre ayrı tablomu oluşturlmalı?
Daha önceleri herbir firma için bir klasör oluşturuyordum ve her firma klasörünün altında çalışılan yıl için bir klasör oluşturuyordum. Dataları bu klasörlerin içinde saklıyordum. Yıl sonundaki devir işleminde de yeni yılın klasöründe dosyaları oluşturup, kayıtları "geçen yıldan devir" diye tek bir kayıtta gelecek yıla devrini yapıyordum.
Bu işelmi Interbase/firebird'de nasıl yapmam gerektiği konusunda fikir verirseniz memnun olurum.
İyi çalışmalar
Ben Sybase kullanarak bu tur işleri hep şu şekilde yapıyorum....
Tek bir veritabanı ve her şirket için de tek tablo.... Sadece firma bazında farklılık gosterecek tabloların primary key 'lerine FIRMA_NO diye bir alan koyup FIRMA isimli bir ana tablonun detayına almıs oluyorum... TAbi firma bazında farklılık gostermeyecek SEHIR gibi ULKE gibi global tablolar bagımsız kalıyor....
Ayrıca her yıl sonunda bir devir olayı da yapmıyorum kesinlikle yıllarca biriken kayıtlar tek bir tablo ve tek bir database uzerinde duruyor....
Bunların avantajları malum. bütün firmalar ve butun yıllar tek bir veritabanı icinde ve aynı tablo icinde olunca konsolide raporlar olsun gecömis yıllara ait raporlar olsun cok kolay olabilmekte ve de yıl devirleri gibi farklı veritabanları olusturma gibi angaryalardan kurtuluyorsunuz....
Gelelim performans yonunden dezavantajına..... bence bunun perofrmans yonunden hic denilebilecek kadar az dezavantajı vardır... Zira gerekli indexler olduktan sonra 10 bin kayıtlık bir tablodan sorgu yapma ile 1 milyon kayıt olan tablodan sorgu yapmak arasında sql temelli bir veritabanı icin fark cok azdır..... Hatta bir cok rapor icin farkı hic bir canlı hissedemez bile.... Misal primary key'i belli olan bir alana konumlanma, indexli bir alana gore kısıtlama ile sorgulama vs..... Yavaşlayacak olan tek rapor grubu konsolide raporlardır ki onları da zaten diger farklı veritabanı yontemlerinde almak zaten bir işgencedir...
Velhasıl zaten bu tür yüklerin altında ezilmedikleri için RDBMS 'leri tercih ederiz....
Daha detalı bilgi için bakınız Seminer 5,6,7,8 kayıtları ve slaytları......
Tek bir veritabanı ve her şirket için de tek tablo.... Sadece firma bazında farklılık gosterecek tabloların primary key 'lerine FIRMA_NO diye bir alan koyup FIRMA isimli bir ana tablonun detayına almıs oluyorum... TAbi firma bazında farklılık gostermeyecek SEHIR gibi ULKE gibi global tablolar bagımsız kalıyor....
Ayrıca her yıl sonunda bir devir olayı da yapmıyorum kesinlikle yıllarca biriken kayıtlar tek bir tablo ve tek bir database uzerinde duruyor....
Bunların avantajları malum. bütün firmalar ve butun yıllar tek bir veritabanı icinde ve aynı tablo icinde olunca konsolide raporlar olsun gecömis yıllara ait raporlar olsun cok kolay olabilmekte ve de yıl devirleri gibi farklı veritabanları olusturma gibi angaryalardan kurtuluyorsunuz....
Gelelim performans yonunden dezavantajına..... bence bunun perofrmans yonunden hic denilebilecek kadar az dezavantajı vardır... Zira gerekli indexler olduktan sonra 10 bin kayıtlık bir tablodan sorgu yapma ile 1 milyon kayıt olan tablodan sorgu yapmak arasında sql temelli bir veritabanı icin fark cok azdır..... Hatta bir cok rapor icin farkı hic bir canlı hissedemez bile.... Misal primary key'i belli olan bir alana konumlanma, indexli bir alana gore kısıtlama ile sorgulama vs..... Yavaşlayacak olan tek rapor grubu konsolide raporlardır ki onları da zaten diger farklı veritabanı yontemlerinde almak zaten bir işgencedir...
Velhasıl zaten bu tür yüklerin altında ezilmedikleri için RDBMS 'leri tercih ederiz....
Daha detalı bilgi için bakınız Seminer 5,6,7,8 kayıtları ve slaytları......
* http://www.fahrettin.org Manzara Fotoğraflarım... 
* http://delphiturkiye.gunduz.info Seminerler...
* http://www.hakmar.com.tr Kalite bir haktır...

* http://delphiturkiye.gunduz.info Seminerler...

* http://www.hakmar.com.tr Kalite bir haktır...

Bunları SQL cümlecikleri ile elde edebilirsiniz. Ayrıca Düşünsenize bir kaç firmanız var tek Stok ve Tek cari den ulaşabiliyorsunuz. Mesala A firması ile B firması arasında Stok hesaplamak zorunda kalmıyorsunuz şirketlerde bu tip hesaplamalara çok ihtiyac duyar.
Kolay Gelsin...
Kolay Gelsin...
Gazete manşetleri
* DİKKAT :Lütfen forum kurallarını okuyalım ve uyalım...!
* Warez,crack vs. paylaşımı kesinlikle yasaktır.
Yani mantığı şöyle açabilirmiyiz. Bulunulan yıldan bir önceki yılda kayıt yapılmış x malzemesinin giren miktarını al, çıkan miktarını düş. fark geçen yıldan devreden miktardır.husonet yazdı:Bunları SQL cümlecikleri ile elde edebilirsiniz.
Kolay Gelsin...
Bir ürünün kartını görmek istersek aynı sorgulama herseferinde yapılıp, sonuç verilecek. Anlatmak istediğiniz mantık bu mu?
İyi çalışmalar.
Bu veya buna benzer olaylar gibi. Algoritma nın nasıl kurulacağına bağlı @Fahrettin Abi zaten bu konuda gerekli bilgiyi verecektir.habim yazdı: Yani mantığı şöyle açabilirmiyiz. Bulunulan yıldan bir önceki yılda kayıt yapılmış x malzemesinin giren miktarını al, çıkan miktarını düş. fark geçen yıldan devreden miktardır.
Bir ürünün kartını görmek istersek aynı sorgulama herseferinde yapılıp, sonuç verilecek. Anlatmak istediğiniz mantık bu mu?
İyi çalışmalar.
Kolay Gelsin...
Gazete manşetleri
* DİKKAT :Lütfen forum kurallarını okuyalım ve uyalım...!
* Warez,crack vs. paylaşımı kesinlikle yasaktır.
Daha gecen hafta soyle bir rapor yaptım.... Istenilen iki tarih aralıgında ilgili urun icin butun stok hareketlerini gosteren en basta onceki donemlerden devreden miktarı gosterip en sonda da bir sonraki doneme devreden miktarı gosteren bir rapor.....
Muhasebe isinden pek anlamam bazı resmi zorunluluklar varsa o baska ama.... bir yıl icindeki hareketler o yıla devir ve o yıldan sonrakine devir bunların hepsi bahsettigim yapı icinden cok raha alınabilecek raporlardır....
Matık dediginiz gibi.... istediginiz donemden onceki butun hareketlerin giris-cikis farkini alıp bu doneme devir olarak en basa koyarsınız..... Bu donem ahreketlerini de altına devam ettiniz mi istediginiz olmus olur....
Kolay gelsin....
Muhasebe isinden pek anlamam bazı resmi zorunluluklar varsa o baska ama.... bir yıl icindeki hareketler o yıla devir ve o yıldan sonrakine devir bunların hepsi bahsettigim yapı icinden cok raha alınabilecek raporlardır....
Matık dediginiz gibi.... istediginiz donemden onceki butun hareketlerin giris-cikis farkini alıp bu doneme devir olarak en basa koyarsınız..... Bu donem ahreketlerini de altına devam ettiniz mi istediginiz olmus olur....
Kolay gelsin....
* http://www.fahrettin.org Manzara Fotoğraflarım... 
* http://delphiturkiye.gunduz.info Seminerler...
* http://www.hakmar.com.tr Kalite bir haktır...

* http://delphiturkiye.gunduz.info Seminerler...

* http://www.hakmar.com.tr Kalite bir haktır...

viewtopic.php?t=644&highlight=referential
adresinde, makale ve ipucu forumunda, fahretttin beyin
bu mesaj ile yukarıdakiler tezat oluşturmuyormu? stok veya cari hareketlerde her kart için devreden bakiye sorgulaması yapmak karmaşa yaratmayacakmı?
kod içinden heryıl ve her firma için yeni tablolar oluşturup, kayıtları saklamak olabilirmi?
iyi çalışmalar
adresinde, makale ve ipucu forumunda, fahretttin beyin
diye bir mesajı var.fahrettin yazdı:Anladığım kadarı ile stok durumu öğrenilmek istendiğinde çalıştıracağınız bir procedure ile o anki stok durumunu hesaplamak ise. En onemli ve bu hali ile bile bu yontemi uygulamanın onundeki engel, yogun stok hareketlerinden sonra bir urun icin anlik stok durumunu ogrenmek icin her defasinda bunu belki binlerce kayit icinden ogrenerek bulmak performans acisindan dogru degil. Gerce kisinin amaci o anki stok durumu nedir diye bir soruya karsilik bir raporda bunu gormek isterse bu raporun gelemesini beklemye tahammul edebilir tabi. Cunku oyle uzun surmez belki de aninda geldigi hissedilir. Fakat program icin bir cok hesap sırasında o anki stok durumlarinin kontrol edilmesi gerektigini dusunursek eger. Bir takım hos olmayan yavaslamalara ve veritabanı sunucusunu gereksiz bir yogunluga itmis oluruz. Mesela stok miktarinin negatife dusmesini engellemek istiyorsaniz her kayıt guncellemede bu procedure'un calismasi ve mevcut data ile degil guncellenmek istenen data ile birlikte stok miktarının sifirin altina dusecegini tespit ederek bu duruma engel olmak gerekmektedir. Oysa makalade onerilen yontem ile URUN_STOK tablosuna bir check constraint koyarak bu durum halledilir... Bu ve bunun gibi bir takim kontrolleri de dusunursek diger deavantajlarina paralel olarak belki de yazilan toplam kod daha bile fazla olabilir.
bu mesaj ile yukarıdakiler tezat oluşturmuyormu? stok veya cari hareketlerde her kart için devreden bakiye sorgulaması yapmak karmaşa yaratmayacakmı?
kod içinden heryıl ve her firma için yeni tablolar oluşturup, kayıtları saklamak olabilirmi?
iyi çalışmalar
Anladıgım kadarı ile farklı iki mesajımda stok hareketlerinin sonucunu bir tabloda tutup anlık stoga oradaki veriden bakmayı onermisken (makale) sizin sorunuza da mevcut hareketlerden istediginiz an stok durumunu cikartabilirsini diye cevap vermisim....
İlk anda celiski gibi gorunmesi konusunda haklısınız.... Oncelikle sunu belirteyim ki kendi ifadelerimin tamamı şahsi tecrube ve kanaatlerimin bir sonucudur... Mutlak dogru oldugunu hiç bir zaman iddia edemedigim gibi sadece de beni baglarlar....
Bu anlamda ben şahsen makalede dedigim gibi bir yontem ile anlık stok durumunu takip ederim.... Yani bir giris oldugunda veya cikis oldugunda stok degerini arttirir veya azaltarak durumu gozlerim... Yontemim budur...
Sizin sordugunuz soruda var olan stok hareketlerinden her zaman istenen sonuc cikabilirden kastım ise şu: Diyelim ki 5 yıllık veriler uzerinden anlık yani şu andaki stok durumunu makalede anlattıgım ve 8 seminerde uygulamalaı yaptıgımız yontem ile alabiliriz...
Fakat bu yontem bize ornegin 3 yıl onceki yıla girerken stok ne idi ve 3. yıl sonundaki stok durumu ne oldunun cevabını veremez... Cunku stok degeri anlık degeri gosterecektir.. Gecmise yonelik her an icin bir stok durumunu goremezsiniz... Ancak eger bunu almanız gerekiyorsa o zaman da yapacak bir şey yok. Mevcut hareketlerden gerekli raporlar olusturulabilir... Kastettigim bu... Nitekim ben her iki yontemi de aynı proje içinde kullanıyorum. Anlık stok durumu makaledeki yontem ile tutulurken. istenilen bir tarih araligindaki hareketleri onceki donem deviri ile birlikte verecek bir rapor talbieini de bu yontem ile yaptım....
Yani bir çelişki değil birbirini butunleyen durumlar oldugunu dusunuyorum....
İlk anda celiski gibi gorunmesi konusunda haklısınız.... Oncelikle sunu belirteyim ki kendi ifadelerimin tamamı şahsi tecrube ve kanaatlerimin bir sonucudur... Mutlak dogru oldugunu hiç bir zaman iddia edemedigim gibi sadece de beni baglarlar....
Bu anlamda ben şahsen makalede dedigim gibi bir yontem ile anlık stok durumunu takip ederim.... Yani bir giris oldugunda veya cikis oldugunda stok degerini arttirir veya azaltarak durumu gozlerim... Yontemim budur...
Sizin sordugunuz soruda var olan stok hareketlerinden her zaman istenen sonuc cikabilirden kastım ise şu: Diyelim ki 5 yıllık veriler uzerinden anlık yani şu andaki stok durumunu makalede anlattıgım ve 8 seminerde uygulamalaı yaptıgımız yontem ile alabiliriz...
Fakat bu yontem bize ornegin 3 yıl onceki yıla girerken stok ne idi ve 3. yıl sonundaki stok durumu ne oldunun cevabını veremez... Cunku stok degeri anlık degeri gosterecektir.. Gecmise yonelik her an icin bir stok durumunu goremezsiniz... Ancak eger bunu almanız gerekiyorsa o zaman da yapacak bir şey yok. Mevcut hareketlerden gerekli raporlar olusturulabilir... Kastettigim bu... Nitekim ben her iki yontemi de aynı proje içinde kullanıyorum. Anlık stok durumu makaledeki yontem ile tutulurken. istenilen bir tarih araligindaki hareketleri onceki donem deviri ile birlikte verecek bir rapor talbieini de bu yontem ile yaptım....
Yani bir çelişki değil birbirini butunleyen durumlar oldugunu dusunuyorum....
* http://www.fahrettin.org Manzara Fotoğraflarım... 
* http://delphiturkiye.gunduz.info Seminerler...
* http://www.hakmar.com.tr Kalite bir haktır...

* http://delphiturkiye.gunduz.info Seminerler...

* http://www.hakmar.com.tr Kalite bir haktır...

estağfirullah..... 

* http://www.fahrettin.org Manzara Fotoğraflarım... 
* http://delphiturkiye.gunduz.info Seminerler...
* http://www.hakmar.com.tr Kalite bir haktır...

* http://delphiturkiye.gunduz.info Seminerler...

* http://www.hakmar.com.tr Kalite bir haktır...
