🚀 go-pugleaf

Maciej Łuszczyński wrote:
[...]
>> Jest jeszcze wymierająca metoda Embeded SQL. Czyli SQL wpisany
>> pomiędzy zwykły kod. Takie coś jest także kompilowane i zamieniane
>> na wywołania funkcji serwera. Komunikacja z zapytaniami następuje
>> przez specjalne współdzielone zmienne.
> Tego nie znam.

Witam!

Bo raczej jest nie używane, czasem dokumentacja o tym wspomina. AFAIK raczej
do
zastosowania z C++.

[...]
>> mięć jedną przewagę w przypadku updateing logic. Można spróbować nie
>> modyfikować wszystkich pól. W przypadku optymistycznego module, może
>> to oznacza, że nie napiszemy zmian dokonanych przez innych. Tak
>> automagicznie działało ADO bez .NET . Ale na ADO.NET ta metoda jest
>> strasznie kłopotliwa więc zwykle wysyła się wszystkie pola do
>> modyfikacji. Za to rozwiązuje się te problemy szukają rekordu, który
>> ma być zmodyfikowany uwzględniając wszystkie pola albo wersje
>> rekordu.
> Jakoś nie jestem przekonany, czy to taka zaleta - nadpisanie tylko
> części pól. Włosy na karku mi się jeżą, jak myślę o takiej spójności.
> Nie bardzo mi się podoba pomysł automagicznego wyszukiwania rekordu do
> modyfikacji. Jestem za spójnym mechanizmem: PK i w oparciu o wartość
> tego klucza wstawiamy bądź modyfikujemy.

O ile dobrze zrozumiałem to tak właśnie działa zwykłe ADO samo przygotowując
zapytania aktualizujące:
http://www.microsoft.com/mspress/books/sampchap/5354f.asp

Jeśli dobrze zrozumiałem, jak twierdzi autor to działa tak:
1. Do szukania rekordu w czasie aktualizacji używany jest klucz główny plus
zmienione kolumny
2. Tylko zmienione kolumny są włączane do SET w zapytaniu UPDATE.

Moim zdanie wygląda, że zapobiega ten sposób działa nadpisanie poprzedniej
wartości na podstawie starej wartości pola. Czy to powoduje jak jakieś
szczególne zagrożenie dla spójności to nie wiem. Integralność jest
sprawdzana przez różne więzy na poziome samej bazy. Być może to nie jest
dobry scenariusz dla aplikacji zdalnie przetwarzającej dane, ale dobry
scenariusz dla pracy użytkownika z danymi. Użytkownik powinien przygotować
dane, natomiast przetwarzanie bazy na podstawie tych danych powinno nastąpić
w transakcji na serwera.

Słyszałem od kogoś, że w Oraclu jest możliwość zakładanie blokad na
pojedyncze pola. Dlaczego blokada na rekord daje spójność w bazie, a na pole
nie? Jak modyfikacje w jednym rekordzie są robione na podstawie drugiego
rekordu, oczywiście poza transakcjami. to problemy pojawią się takie same. W
transakcja to nie ma się na czym zastanawiać. O ile się orientuje to jest
sprawa bazy danych jak rozwiąże problem albo zgłosi dead lock
(zakleszczenie). Czyli nie można zakończyć dwóch transakcji bo wynik jeden
wpływa na drugą, a druga jeszcze nie skończona więc niepewna i na odwrót.

[...]
> Co do ryzyka napisania zmian wprowadzonych przez innego użytkownika:
> na poziomie aplikacji, kiedy użytkownik wywołuje edycję, z serwera
> pobierana jest ostatnia wersja rekordu. Dzięki temu minimalizujemy
> ryzyko dwukrotnego wprowadzania tych samych zmian.

Dane są załadowane do formularza na ekranie, użytkownik na podstawie
istniejących danych wprowadza modyfikacje. Jeśli w tym czasie, ktoś inny
wpadnie na ten sam pomysł i nastąpi zatwierdzenie jedno po drugim to
procedury składowane na to zaradzą. Musi być przyjęta jakaś strategia, może
być kto ostatni ten lepszy :-)

> Jeśli zachodzi konieczność wyłącznej edycji rekordu, stosujemy albo
> blokady na poziomie aplikacji (oczywiście wtedy sprawdzane jest to w
> momencie rozpoczęcia edycji, nieco trudniej kontrolować ten mechanizm
> w procedurach składowanych (a w zasadzie wymaga to większej uwagi))
> albo SELECT z odpowiednimi parametrami.

Jest to rozwiązanie mniej skalowane i nie zalecane. Jeśli bym sobie pozwolił
na blokowanie rekordu to wstawił bym na formularzu Timera i dał
użytkownikowi określony czas na dokonanie zmian. Jeśli ktoś pójdzie na obiad
to zablokuje pracę na części danych. Chyba jedna model optymistyczny jest
lepszy i lepiej rozwiązywać problemy niż im zapobiegać.

Poza tym takie rozwiązanie z blokowanie działa wtedy kiedy istnieje
bezpośrednie połączenie z bazą danych, zajmuje zasoby serwera, generuje ruch
na sieci. Nie mam z tak wymagającymi problemami do czynienia ale wydaje mi
się, że model optymistyczny jest jednak lepszy jak proponuje literatura. Na
pewno jest rozwiązanie bardziej skalowane i chyba jedyne do zastosowania w
aplikacjach ASP.

> Jeśli dobrze pamiętam bieg niniejszego wątku, początkowy problem
> dotyczył aktualizacji i zapisu dużej liczby danych. IMO bezwzględnie
> najszybsze będą
> w tym przypadku procedury składowane, najwygodniejsze, jeśli da się je
> połączyć z SQLDataAdapterem (a powinno to być możliwe).
[...]

No właśnie, być może skalowalność rozwiązania ma tu także znaczenia. Ale
autor chyba bardziej miał problemy bardziej od strony kilenta niż serwera.
Procedury składowane można z SQLDataAdapterem, jest rozwiązanie zalcena w
książce, której link podałem wcześniej. Gdzieś wyczytałem, że zwracanie
danych przez procedury składowane ma także swoją specyfikę w czasie odczytuj
danych. MS SQL Server tworzy do tego sepcjany kursor. Przetłumaczyłem jego
nazwę jako "wąż strażacki". Napełnia buffor rekordami i czego na jego
opróżnianie nie prosząć kilenta o rozkazy wysyłania rekordów. Ma to być
rozwiązanie bardziej skalowane bo zmiesza ruch tła w sieci.

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