Odp: Efektywność dostępu do zapisów - cd

["Siergiej Szablykin" <SSzablykin@lukas.com.pl>]

     Jeżeli liczność zbioru C będzie mała (rzędu 1000 rekordów), albo rozkład występowania w tabeli B elementów rodzaju Ci nie jest normalny (liczba elementów rozdaju Cn >> Cm) to zapytania wykorzystujące klucz C mogą być mało efektywne. Oprócz tego trzeba zwrócić szczególną uwagę na zapytania wykorzystujące oba pola (klucz A + klucz C) i kompilować je z x-ref'em, bo Progress może inaczej ziterpretować zapytanie niż programista, który go napisze.
    Natomiast jeżeli chodzi o zmianę struktury takiej tabeli, to jest to rzeczywiście bolesne przerzycie. Natomiast zawsze można dodawać nowe pola ze znakiem '?' jako wartością domyślną i później ewentualnie nadać właściwą wartość (nie powinno zająć to więcej niz 12-24 g.). Natomiast dodawanie indeksów można zrobić własciwie tylko w jeden sposób - dodać indeks jako zdeaktywowany, a póżniej go odbudować off-line. Inne rozwiązania wymagają bardzo dużo miejsca na BI oraz mogą trwać tygodniami (o tym słyszałem, natomiast sam nidy nie miałem cierpliwości czekać na coś powyżej 24 g. i przerywałem podobne eksperymenty, także przenoszenie tabeli pomiędzy obszarami)

Z poważaniem,
Siergiej Szabłykin.


>>> henju@pg.gda.pl 05/08 9:49  >>>
Witam !

Dziękuję za odpowiedzi, zwróciły one moją uwagę na kilka aspektów 
posiadania tak dużych tablic. Do tej pory najliczniejsza tablica w naszej 
bazie (wersja 9.1B) zawiera 2,5 miliona zapisów i zachowuje się przyzwoicie.
Stoję przed problemem jaką reprezentację wybrać dla poniższej struktury danych:

  -------------
  |     A     |   Zapisy nagłówkowe paczki
  |           |
  -------------
        |
       /|\
  -------------   Paczki wartości trzymane w tablicy B
  |     B     |   przypisane do zapisu nagłówkowego A
  |           |   Rodzaj każdej wartości określony w tablicy C
  -------------
       \|/
        |
  -------------
  |     C     |
  |           |   Rodzaj wartości
  -------------

Jak widać z obrazka (jeśli w ogóle coś widać) chodzi o tablicę B która jest 
realizacją typowego związku wiele-do-wielu, tyle że bardzo liczną (jak 
pisałem 100 - 200 milionów zapisów). Tablica B będzie miała:
   - klucz obcy z tablicy A (jedno pole INTEGER)
   - klucz obcy z tablicy C (jedno pole INTEGER)
   - pole z wartością (DECIMAL)
oraz indeksy:
   - indeks podstawowy: Klucz A + Klucz C
   - indeks dodatkowy : Klucz C
Dostęp to najczęściej odczytanie zapisu A i paczki związnych z nim zapisów 
B z ewentualną selekcją ich rodzajów wg klucza obcego C.
     FOR EACH B OF A WHERE 
Dużo rzadziej dostęp typu "FIND FIRST B OF C" w celu zachowania integralności.

Alternatywą jest reprezentacja nierelacyjna, gdzie występuje tylko tablica 
A o strukturze:
   - klucz tablicy A
   - inne pola tablicy A
   - wektor wartości (EXTENT) zawierający tyle elementów ile wynosi:
     Max(wartość klucza C) - Min(wartość klucza C) + 1 = około 300 do 400
Indeks podstawowy: Klucz A
Wartość związana z kluczem C byłaby trzymana w wektorze na pozycji 
wyznaczonej przez ten klucz. Duża część (80% do 90%) wartości w wektorze 
byłaby zerowa.
W tej reporezentacji byłby czytany cały zapis A a selekcja wartości 
odbywałaby się w programie poprzez wybór potrzebnych elementów wektora.
Rozwiązanie to ma oczywiście wady:
   - większość elemmentów wektora zerowa (chociaż zera Progress ładnie pakuje)
   - większe zapisy w bazie i w transmisji
   - kłopoty, jeśli trzeba będzie zwiększyć rozmiar wektora
   - kłopoty z integralnością - nie można stwierdzić, czy klucz tbalicy C jest
     gdzieś użyty
   - generalnie nie lubię rozwiązań nierelacyjnych, bo to przeważnie źródło
     kłopotów
   - też nie mam doświadczeń z plem wektorowym zawierajacym 300 do 400 
elementów

Przy mniejszej liczności tablicy B bez żadnych wątpliwości wybrałbym 
reprezentację pierwszą (relacyjną), jednak przy dużej liczności ogarnęły 
mnie obawy co do efektywności, gdzyż nie mam doświadczeń z tak dużą 
tablicą, natomiast mam doświadczenie, że "papier wszystko wytrzyma, a w 
praktyce bywa różnie".

Jeszcze uwaga natury ogólnej - myślę, że przedstawiona przeze mnie sytuacja 
jest dość typowa i ciekawe są doświadczenia z różnych wariantów jej 
rozwiązania. O ile mnie pamięć nie myli, to w niektórych bazach (Sybase ?) 
takie tablice asocjacyjne mają specjalną reprezentację w bazie. A może w 
większości naszych przypadków tablica B ma przyzwoitą liczność i każdy 
wariant funkcjonuje w miarę sprawnie ?

Pozdrawiam,


Henryk Jusza               mailto:henju@pg.gda.pl 
-------------------------------------------------
Ośrodek Informatyczny Politechniki Gdańskiej
Pracownia Rozwoju Oprogramowania
tel (058) 347-28-01          fax (058) 347-24-63
------
Strona WWW:     http://pluton.pol.lublin.pl/pugpl/index.htm
Obsluga listy:  listserv@zeto.bydgoszcz.pl
Archiwum listy: http://www.zeto.bydgoszcz.pl/progress/index.html
------