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

[Henryk Jusza <henju@pg.gda.pl>]

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
<warunki_selekcji_wg_klucza_C>
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