🚀 go-pugleaf

>> A nie jest tak, ze kazde zapytanie przychodzace do SQL Servera jest
>> parsowane, a nastepnie tworzony jest plan wykonania zapytania, pod
>> warunkiem, ze nie jest to odwolanie do funkcji lub procedury? Czyzby
>> DataAdapter potrafil to obejsc? Chetnie dowiem sie czegos wiecej ww
>> temacie.
> Nie, chodziło mi to co się dzieje po stronie klienta. Np. zapytanie
> modyfikacji tabeli może być bezpośrednio wprowadzone w czasie tworzenia
> aplikacji do obiektu Command w DataAdapterze albo generowane dynamicznie
> przez SQLCommandBuilder. Ta druga metodę ma tą niedogodność, że musi odpytać
> bazę danych o strukturę tabeli aby móc takie zapytanie wygenerować.
Spory spadek wydajności IMO. Poza tym staram się stosować zasadę
ograniczonego zaufania i powtarzalnych wyników: do serwera powinno docierać
zawsze to samo. IMO.

> Jeśli chodzi o stronę serwera podobno można obejść proces prasowania
> zapytania.
Zdecydowanie można, ze względu na wydajność nawet należy :) Ale nie
parsowania, tylko układania planu wykonania zapytania.

> Po pierwsze serwery mogą posiadać własne API. Może to być metoda
> wydajniejsza ale na pewno nie łatwiejsza w używaniu.
To dylemat stary jak świat. Trzeba coś wybrać :)

> Po drugie procedury składowane. Podejrzewam, że ich użycie nie wiąże się z
> prasowaniem ich treść za każdym razem. Procedury składowane są preferowane
> do załatwiania updateing logic. Ale niestety zarówno AFAIK genertor zapytań
> zawarta w IDE jaki i SQLCommandBuilder nie pomogą w ich używaniu.
Zarówno procedury, jak i funkcje składowane to po prostu skompilowane plany
zapytania, przechowywane na serwerze. Wywołanie takiej procedury wymaga co
prawda sparsowania (choćby po to, by odczytać parametry, by była możliwość
przekazania wartości z procedury, itp.), ale nie wiąże się (ze zwykle dużo
kosztowniejszym) układaniem planu zapytania.

Nie używam SLQCommandBuildera, za to dość często procedur i funkcji
składowanych. Nie wiem, czy zależy to od wersji VS, ale w moim przypadku
wystarczy po prostu z eksploratora serwera przeciągnąć odpowiednią
procedurę do formatki, a IDE automatycznie stworzy odpowiedni obiekt wraz z
listą parametrów. Konieczne jest następnie przypisanie wartości wszystkim
parametrom (ja robię to ręcznie), ale zakładam, że można zmusić
SQLDataAdapter (nie używam go do aktualizacji) do odpowiedniego
wykorzystania procedury składowanej i automatycznego podstawienia wartości.

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

> Korzystając SQLCommandBuilder nie dosyć, że powoduje interpretacje kodu to
> także generacje tego zapytania. Generowanie zapytania może 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.

Troszkę pozwolę sobie opowiedzieć, dlaczego wolę/wolimy procedury
składowane. Jest to ostatni bastion logiki aplikacji. Oczywiście, można
zrobić to samo na triggerach i ograniczeniach, ale procedury wydają się
łatwiejsze w pielęgnacji, debuggowaniu i kontroli. No i całkiem szybkie
przy zapisach dokumentów składających się z wielu linijek. Procedury
działają oczywiście w ramach transakcji, więc spójność danych jest
zachowywana.

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. 

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.

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

Pozdrawiam
-- 
Macko
*** A czym się różni Cray od normalnego peceta?
*** Tym, że Cray wykonuje pętle nieskończone w 10 sekund.