🚀 go-pugleaf

Grzegorz Skoczylas <grzegorzs@rekord.com.pl> napisał(a) w artykule
<371add68.0@news.vogel.pl>...
> 
> "Procedura" była bardzo prosta.  Zadawałem różne proste, złożone i bardzo
> złożone zapytania SQL.  Czas odpowiedzi był zawsze porównywalny.
> 
> Przez bardzo złożone zapytania mam na myśli zapytania pobierające dane z
> wielu tabel (LEFT JOIN) i w warunku WHERE zawierające kilka
zagnieżdżionych
> instrukcji SELECT.

Chodziło mi np. o to, czy uwzględniałeś działanie cache'ów przy wykonywaniu
testów. Zrobiłem jednak własne testy i ich wyniki potwierdziły to co
podałeś. Jednakże FIB jest zdecydowanie szybszy przy odświeżaniu małych
tabel (450 rekordów) - czyli pierwsze zapytanie i ponowienie zapytania. Na
jego korzyść wypada też test polegający na przejściu do ostatniego rekordu
po wykonaniu zapytania (4 razy szybciej niż SQL Explorer! - 450 rekordów)
Przy większych tabelach (7000 rekordów) FIB wypada bardzo podobnie do BDE,
a w niektórych przypadkach jest nawet nieco wolniejszy.
Zrobiłem też test polegający na wyświetleniu trzech tabel - jedna główna i
dwie poboczne. W tabelach pobocznych wyświetlałem tylko rekordy związane z
bieżącym rekordem tabeli głównej. W tym przypadku program oparty FIB był
szybszy niż taki sam program używający BDE.
Jeśli więc chodzi o szybkość to trzeba użyć tego mechanizmu, którego zalety
lepiej wykorzysta aplikacja.
Do zalet FIB należą też:
1. Możliwość dostępu do API IB,
2. Możliwość wykorzystania mechanizmów IB - np. ROLE lub parametry
transakcji.
3. Prawdopodobnie FIB daje możliwość na pracy na kilku transakcjach w
ramach jednego połączenia z bazą danych.
4. Dostęp do kodu źródłowego
5. Prawidłowe działanie właściwości RecNo - dla osób chcących wyświetlać
liczby porządkowe to prawdziwe zbawienie, nie mówiąc o tym jak wygląda
pasek do przewijania grid'a.
6. Prostota instalacji (u klienta)

Do ostatecznej oceny trzeba by jeszcze było sprawdzić jak szybko działa
zmiana i dodawanie rekordów. 

Traptak