🚀 go-pugleaf

Jacek Wołoszka wrote:
[...]
>> Chodzi o prace z warstwa ADO.Net i duzymi bazami danych. Dotychczas
>> pracowalem poprzez DataSet i wszystkie zmiany wykonywalem na nich.
>> Ale od momentu jak zaczalem pracowac z tabelami o milionie rekordow
>> taka praca stala sie porazka. Zreszta moze cos zle robie?
[...]

Witam!

Mój najnowszy pomysł co prawa dotyczy zwykłe ADO bez .NET-u, ale myślę że ma
także odniesie tutaj. To, że nie wolno w takim przypadku sprawdzać
wszystkich rekordów to na pewno jest prawa. Z tego co się orientuje samo ADO
(bez .NET) działa podobnie przy kursorze ustawionym na ClientSide. Jeszcze
muszę sprawdzić w informacje o providerze Accessa, ale na pewno tak się
dzieje w przypadku MS SQL. Odchodzi się o tego, że aplikacja jeździ kursorem
po serwerze. Używane są kursory jednokierunkowe, a najlepiej przesłanie
rekordów przez sieć w trybie "węża strażackiego" aby zmniejszyć ruch tła w
sieci. Kiedy aplikacja tak podchodzi do pracy z serwerem będzie mogła
pracować z wieloma serwerami i sama staje się skalowana. Będzie właśnie
mogła działać w większej skali :-) Podobnie wpływa optymistyczny model
lokowania, pesymistyczny jest do przyjęcia tylko w małej skali.
Tyle podłoża teoretycznego.

Zatem jak sobie poradzi skoro aplikacja musi przyjąć odpowiedź na zadane
pytania i to jak najlepiej nie powodując niepotrzebnego ruchu w sieci. Musi
pobrać co jest w danym momencie potrzebne pod dwoma względami. Zarówno pod
względem ilości wierszy i kolumn. Przy założeniu, że średnio każde pole
zajmuje tyle samo miejsca, obcięcie o połowę ilości wierszy i kolumn obniża
czterokrotnie ilość potrzebnej pamięci i transfer przez sieć.

Zatem po pierwsze przygotowujemy zapytanie do widoku listy czy grida,
zawierające tylko niezbędne kolumny, które użytkownik będzie widział oraz
oczywiście wiesze. W najgorszym wypadku pobierzemy tylko x-rekordów. Być
może było by celów dać możliwości ustawiania tego x-a w opcja i ostrzeganie
użytkownika, że przekroczony został ten limit.
Natomiast w przypadku edycji danych pobieramy z bazy do edycji tylko
edytowany rekord i umieszczamy w osobnej tabeli. W tym przypadku zwykle
pobiera się wszystkie kolumny, choć to raczej nie ma pamięciowo znaczenia.
Problem pojawia się jak wyślemy taki rekord z powrotem. Najprawdopodobniej i
tak najrozsądniej będzie posiada dostęp do wszystkich pól. Zależy od modelu
radzenia sobie z sytuacja, że jak użytkownik edytuje dane coś ulega zmianie.

Tak więc do edycji i poglądu mamy dane w osobnych tabela. Jeśli dopuścimy
taką sytuacje to najprawdopodobniej powstanie problem synchronizacji. Po
zmianie trzeba przeładować dane do poglądu. Ma to o tyle sens, że
przekonujemy się jak dane wyglądają na serwerze po zatwierdzeniu zmian.
Powoduje niestety ciągnięcie wszystkiego od nowa przez sieć. Chyba można
temu zaradzić zatwierdzając rekordy paczkami. Jest i problem w drugą stronę.
Użytkownik wybierając edycje może dostać rekord trochę nowszy niż widział go
w poglądzie rekordów.

Szczerze mówiąc nie testowałem tych pomysłów w jakieś wielkiej skali. Ale
wyda, że mają one ręce i nogi.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_m...@gazeta.pl ]