🚀 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

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

"Jurek M." napisał(a):

[bardzo rzeczowe, niemniej ciach...]

> 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).

Wiem, wiem, wiem... Chwilowo musimy sobie radzić inaczej, ale docelowo
będziemy walczyć na serwerze SQL (pytanie brzmi - jakim, mamy pewne
problemy z wyborem platformy). Dzięki za rzeczową odpowiedź. Co za
przyjemna grupa news... 
Zdrówko
Jarek Zgoda