Tüm Platformlar için Hızlı Uygulama Geliştirme --->    Kitabımız...      Delphi

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 4/5 - 1 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Firebird veritabanı yapısı hakkında öneri
#1
Merhaba, hazır konu hakkında deneyimli üstadlar varken bir veritabanı yapısı hakkında öneri almak isterim. Konuyu okuyan arkadaşlar içinde yol gösterici olur.
Şöyle bir veritabanımız var (Kısaltarak yazıyorum alanları);
CARI_HESAP tablosu ; KOD, UNVAN, BORC, ALACAK
STOK tablosu ; KOD, ADI, GIREN, CIKAN
FATURA_1 tablosu ; KOD, TURU, CARIKODU, TUTAR, BORC, ALACAK
FATURA_2 tablosu ; KOD, FATURA1KODU, TURU, CARIKODU, STOKKODU, MIKTAR, GIREN, CIKAN
(TURU alanı BYTE tipinde 0:ALIS FT. 1:SATIS FT. şeklinde)
(FATURA_1 tablosunda Before Insert olayında ALIS yada SATIS faturası olması durumuna göre TUTAR alanı BORC yada ALACAK alanlarına yazılıyor)
(FATURA_2 tablosunda Before Insert olayında ALIS yada SATIS faturası olması durumuna göre MIKTAR alanı GIREN yada CIKAN alanlarına yazılıyor)
(FATURA_1 tablosunda After Insert olayında CARI_HESAP tablosundaki BORC, ALACAK alanları güncelleniyor)
(FATURA_2 tablosunda After Insert olayında STOK tablosundaki GIREN, CIKAN alanları güncelleniyor)

CARI_ISLEM View'i
CREATE VIEW CARI_ISLEM(
    KOD,
    TURU,
    ACIKLAMA,
    CARIKODU,
    BORC,
    ALACAK)
AS
select KOD, TURU, CARIKODU, BORC, ALACAK 
from
(
SELECT F.KOD,
F.TURU,
CASE
WHEN F.TURU=0 THEN 'Alis Ft.'
WHEN F.TURU=1 THEN 'Satis Ft.'
END AS ACIKLAMA,
F.CARIKODU,
F.BORC, 
F.ALACAK
FROM FAT1 F
)
View i kısaca yazdım, normalde içinde çekler, tahsilat ve ödemeler vs.vs. var. Cari hareketlerini bu şekilde gösteriyorum.
Cari hesapları listelerkende hazır BORC, ALACAK kayıtlı olduğu için direk Grid de gösteriyorum, altında da işlemleri tabi.

Fakat bunu şu şekilde de yapabiliyoruz;
FATURA tablolarındaki Before Insert ve After Insert olaylarını iptal edip, CARI_HESAP tablosundan da BORC ve ALACAK alanlarını kaldırıyoruz.
CARI_HESAPLAR View i oluşturuyoruz;

CREATE VIEW CARI_HESAPLAR(
    KOD,
    UNVAN,
    BORC,
    ALACAK)
AS
select KOD, UNVAN, COALESCE(BORC,0), COALESCE(ALACAK,0)
from
(
SELECT C.KOD as KOD, C.UNVAN AS UNVAN, 
       sum(F.BORC) AS BORC, sum(F.ALACAK) AS ALACAK
FROM CARI as C
LEFT JOIN
(SELECT CARIKODU AS KOD, SUM(BORC) as BORC, SUM(ALACAK) AS ALACAK
 FROM FATURA_1
 GROUP by CARIKODU
 ) as F on F.KOD = C.KOD
 GROUP BY C.KOD, C.UNVAN
)

2. olaydaki amaç Fatura, Çek vs. kaydederken After Insert olayındaki CARI ve STOK tablolarındaki alanların güncellemelerini kapatmak. Kısaca trigger kullanımını en aza indirmek.

Sizce bu 2 sistemden hangisi daha uygundur? hangisi daha hızlı ve daha hatasız çalışır?
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#2
Kişisel tecrübelerime göre, içerisinde JOIN bulunan sorgular performansta ciddi çekilde fark ediyor. Eğer yukarıda yazdığın iki sorguda da aynı sonuçlara ulaşabiliyorsanız, üstteki VIEW daha kullanışlı ve performanslı olacaktır. Bir de, ikinci view'ın sorgusunda gördüğüm kadarıyla SUM alma durumları da var. Bu da, her bir cari hesapta gezerken bu işe de ayrıca zaman harcayacağı anlamına geliyor. Yani benim fikrim, ikinci View'ın daha yavaş çalışacağı yönünde. Ben olsam birinci şekilde devam ederim.

Ben kendi yazdığım uygulamalarda performansa çok önem verdiğim için konuya bu açıdan yaklaştım. Diğer deneyimli hocalarımızın da fikirlerini merak ediyorum Smile

E.O.F.  (End Of Fun )
Rolleyes
Cevapla
#3
Hocam yorumun için teşekkürler, bende 1. şekilde kullanıyorum şu anda fakat orada kullandığım AfterInsert triggerları performansa çok fazla etki edermi ? Yada etse bile aşağıdaki şekildeki kullanımdaki sum alanları daha fazlamı yoksa azmı etki eder? Özellikle bir firmada aşırı derecede fatura kesiliyor (40-50k arası). Birkaç test yaptım aslında 2. şekildeki kullanımda özellikle stok listesi almak istediğimde bariz yavaşlama görüyorum. Birde en önemli olan sorun, hangisi daha güvenli olur?
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#4
İkisi de güvenlidir, ama dediğim gibi (ki sen de fark etmişsin ) ikinci sorgu daha yavaş çalışır (JOIN ve SUM'lar dan ötürü )
Trigger bende kullanıyorum, Trigger içinde çok uzun sürecek işlemler yapmıyorsan JOIN'li sorgulardan daha hızlı çalışır. Çünkü Trigger'ların kontrolü senin yazdığın kodda değil, Firebird'ün kontrolünde olduğu için performans anlamında sorun yaşamazsın. Benim her tablomda update,insert ve delete olaylarında trigger'lar çalşır ve şimdiye kadar hiç performans sorunu yaşamadım.

Hatta şunu söyleyim, ben çoğu zaman kendim Delphi veya C# kodları ile veritabanı işlemleri yapmaktansa, belirli bazı işleri Firebird'e yıkıp Trigger'lar sayesinde işleri orada yaptırıyorum Smile

E.O.F.  (End Of Fun )
Rolleyes
Cevapla
#5
Merhaba,
Sorgu hızını etkileyen faktörlerin (donanımsal özellikler hariç) başında Where, When, Having ve Join direktiflerinde kullanılan tablo alanlarının index durumları gelmektedir.  
Sorgu performansı için bu bölümlerde kullanılan her tablo alanları için ayrı ayrı ve kombinasyonlu indexlerin oluşturulması gerekiyor.
Örneğin Join bölümünde geçen F.KOD = C.KOD için her iki alanın ayrı ayrı indexlenmesi gerekiyor.
Yada bir Where bölümünde Ad, Soyad, TC alanı şart koşuluyorsa; Ad, Soyad, TC, AdSoyad, AdTC, SoyadTC, AdSoyadTC gibi indexlerin oluşturulması gerekiyor.
Trigger, procedure, function veya benzeri kombinasyonlu (Sequence, Generator vb.) RDBMS işlemlerinin sorgu (Select) hızına doğrudan bir etkisi yoktur (sonuç bekleyen sorgu işlemleri hariç).
Bu işlemler, sunucunun fiziksel kapasitesi (RAM, İşlemci Türü, Çekirdek sayısı, Sanal Bellek vb), OS (Unix, Win vb.) ve Veri Tabanı türüne bağlı olarak, dolaylı yollardan etkilenmektedir. (Yapılan her bir DB işleminin kuyruğa alınması ve buna bağlı olarak işlem görme süresinin uzaması gibi)
Güvenlikle ilgili bir sorunuz var;
Sorgularda DB sistemine sızma veya sorgu parametrelerini devre dışı bırakma gibi SQL Injection tekniklerini kastediyorsanız (ki diğer türlü, güvenlik tamamen fiziksel veya sanal güvenlik duvarı veya sistemleri ile ilgilidir.); bu tip tedbirler DB tarafında değil, tamamen kodlama teknikleri ile devre dışı bırakılmaktadır.
While true do; Hayat döngüsü, kısır değildir! Yapılan bir yanlış, o döngünün dışına çıkmanızı sağlayacaktır.
WWW
Cevapla
#6
Yorumlar için tekrar teşekkürler, kafadaki soru işaretleri ortadan kalktı çok şükür. Sadece şu karışık indexleri yeniden düzenlemem gerebilir. Şu an için güvenliğe hemen hemen hiç önem vermiyorum, ilerleyen zamanlarda artık oada bi çare bulucaz inşallah.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter



Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  Firebird Uzak veritabanı yedekleme masteryoda 9 949 26-01-2018, Saat: 17:47
Son Yorum: rmzgenius
  Firebird -arithmetic exception, numeric overflow masteryoda 11 1.050 26-01-2018, Saat: 17:39
Son Yorum: rmzgenius
  FireBird veri tabanını nereden indirebilirim? Coder 4 1.666 26-01-2018, Saat: 17:32
Son Yorum: rmzgenius
Question Firebird Kayıt Kilitleme masteryoda 4 197 20-12-2017, Saat: 09:59
Son Yorum: Abdullah ILGAZ
  Firebird'ü buluta taşıma işlemi habilkader 2 199 13-12-2017, Saat: 14:00
Son Yorum: rmzgenius



Konuyu Okuyanlar: 1 Ziyaretçi