🚀 go-pugleaf

Maciej Łuszczyński wrote:
>> Jeśli dobrze zrozumiałem, to zamiast przygotować zapytanie w
>> aplikacji, tworzysz je dynamicznie w czasie pracy programu. Otóż
>> wyczytałem, że taki sposób jest o tyle nie ekonomiczny że aplikacji
>> traci czas na przepytywanie serwera o strukturę tabeli. Było właśnie
>> było to jeden z powodów wyboru rozwiązania z osobny DataAdapterem.
>> Więc chyba jeśli nie ma innej potrzeby warto przygotowywać zapytania
>> w czasie projektowania aplikacji.
> 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.
[...]

Witam!

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

Jeśli chodzi o stronę serwera podobno można obejść proces prasowania
zapytania.
Po pierwsze serwery mogą posiadać własne API. Może to być metoda
wydajniejsza ale na pewno nie łatwiejsza w używaniu.
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.
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.
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.

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