🚀 go-pugleaf

Jarek Zgoda napisał(a) w wiadomości: <373686D8.E83967D1@polanglo.pl>...
>Czołem Panie i Panowie,
>mam małe pytanko. Otóż, po przeczytaniu kilku(nastu) postów nt.
>komponentów dostępu do danych, postanowiłem sprawdzić ich szybkość.
>Wszyscy polecali stosowanie komponentu TQuery zamiast TTable, więc na
Ciach ...

Cześć,  Moje doświadczenia są następujące:

1. Zasada generalna dla wszystkich baz odnośnie indeksów:

    Dla wszystkich (DBase, Paradox, SQL i innych):
        - załóż dobrze przemyślane indeksy

    Dla baz plikowych (DBase, Paradox):
        - jeżeli zamierzasz korzystać z TTable, mogą one być w zasadzie
dowolne,
          ale dobrze będzie jak będą wspierać stosowane w aplikacji filtry i
zakresy
          oraz oczywiście wymagane sortowania
        - jeżeli zamierzasz stosować TQuery to indeksy powinny być proste,
          tzn. po jednej kolumnie. Powinny one dobrze wspierać stosowane w
aplikacji
          polecenia SQL w zakresie selekcji wierszy i sortowania. Stosowanie
indeksów
          złożonych (po wielu kolumnach lub stosowanie wyrażeń w DBase) może
          spowodować, że taki index będzie dla "Local SQL-a" bezużyteczny
lub będzie
          wykorzystana jedynie pierwsza kolumna

2. Do baz plikowych (DBase, Paradox)
        - jeżeli zamierzasz prezentować w DbGrid-ach długie listy, np.
zestawienia
          obrotów z całych miesięcy lub lat (ja mam w FK ok. 25.000 zapisów
/ miesiąc),
          to stosuj TTable. Po ustawieniu odpowiednich relacji, indeksów i
ewentualnie
          zakresów (z filtrami ostrożnie) wyświetlanie wierszy jest
natychmiastowe.
          Przy stosowaniu relacji trzeba być czujnym przy dopisywaniu nowych
wierszy
          i aktualizacji pól w wierszach istniejących, ale to daje się
zrobić w miarę gładko.
          Gdybyś tutaj stosował TQuery, to pamiętaj, że Local SQL buduje
folderze roboczym
          kursor będący odpowiedzią na zapytanie w postaci pliku DBase lub
Paradox
          (w zależności od default drivera dla Database / Aliasu)
zawierającego WSZYSTKIE
          wiersze wynikowe tego zapytania; nie ma tutaj możliwości
pobierania (fetch)
          po kawałku. Nawet przy poprawnych indeksach to budowanie kursora
          (zapis na dysk) zabiera najwięcej czasu i jest dla użytkownika
irytujące,
          np. wynik zawierający 50.000 wierszy.

        - jeżeli możesz sobie pozwolić na interfejs prezentyjący aktualnie
pola jednego wiersza
          (ew. kilku do kilkudziesięcu), to wybierz TQuery. Jest to
rozwiązanie bardziej
          uniwersalne, bo będzie dobrze obsługiwać zarówno bazy plikowe jak
i SQL-owe,
          i możesz też stosować 'casched updates' jeżeli chcesz. Dla zapytań
SQL możesz
          założyć dodatkowe indeksy proste. To będzie też dobre dla baz
Accessa.

        - albo stosuj rozwiązanie mieszane (ja tak robiłem dopóki nie
przestawiłem się całkowicie
          na bazy SQL-owe). Do prezentacji długich list stosuj TTable, a w
przypadku wyrafinowanych
          zapytań zwracających rozsądną liczbę wierszy (ja założyłem do
kilkuset) stosuj TQuery.
          Nie musisz sie wtedy przejmować relacjami, zakresami, filtrami i
sortowaniem. Chociaż
          w takich przypadkach kursory wynikowe są zazwyczaj 'not
updateable' i trzeba to sobie
          jakoś obsłużyć, ale to też nie problem. I dla baz Paradoxa uważaj
abyś nie popadł
          w problem 'Lock file has grown too large' jak to miał kolega 'sir
pawian' w wiadomości
          z dnia 30.04.1999 i poprawnie ustaw foldery: sieciowy i roboczy.

3. Dla baz SQL-owych generalnie stosuj TQuery; bez dalszego komentarza.
    Ale pamiętaj o właściwych indeksach i optymalizacji zapytań (uwzględnij
PLAN).

4. Dla baz Accessa sprawa jest bardziej złożona. Otóż obsługa tych baz
wymaga obecności
    DAO, a to oznacza już dwóch pośredników w dostępie do bazy (BDE i DAO).
    I w dodatku aby korzystać z takiej aplikacji (lub sprzedawać ją) musisz
mieć legalne DAO
    ew. z licencją do dystrybucji (chyba , że założysz, że aplikacja
współpracuje z taką, która
    ma legalne DAO).
    Z konieczności popełniłem kiedyś jedną aplikację z bazami Accessa, ale
wybrałem do tego
    Visual C++ (ale mi visual !?) i chodziło bardzo sprawnie, ale w Delphi
przygotowanie
    aplikacji jest dużo bardziej przyjemne. Ale dla baz Accessa jest to
chyba najlepsze wyjście.

Jak widzisz, wybór metody zależy od problemu, projektu aplikacji i
wykorzystywanych
baz danych. Gorąco polecam bazy SQL-owe. Dla mniej zamożnych klientów można
postawić server niekomercyjny (Linux + MySQL, PostgreSQL, Interbase 4), a
dla bogatszych
Oracle, Informix czy MS SQL. A zapewniają one bardziej komfortową pracę
zarówno
dla producenta oprogramowania jak i użytkownika (i można zarobić na
postawieniu servera).

Pozdrowienia, Jurek M.  e-mail: jurek1@box43.gnet.pl