Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
Sam język zapytań wypisz wymaluj cały FOX.
Więc pytanie brzmi: w czy jest SQL lepszy od FOXA lub nawet Clippera obu sprzed 20 lat.

Aaa...w zasadzie nie powinienem się wypowiadać. Bo przecież nie znam Clippera. Ale...

1. że SQL "działa" "mniej więcej" tak samo na wszystkich bazach już od lat - chwała za to standaryzacji ! Choć do dziś niestety różnice się zdarzają.
2. Dyskusja przypomina mi tą, którą toczyłem gdzieś ostatnią, gdzie udowadniać mi przyszło wyższość komercyjnego MS-SQL na darmowym MySQL. I co się okazało ? W typowych przypadkach, w zasadzie bazy działają podobnie - ale diabeł tkwi w szczegółach:
- we współczesnych komercyjnych bazach nie stanowi problemu wykonanie jej backupu przy zachowaniu ciągłości pracy. Banalne ? A jednak już np. w MySQL jest to "jakiś" problem. A jak było w Cliperze ?
- współczesne komercyjne bazy danych dają możliwość odtworzenia historycznego stanu bazy danych, np sprzed 10 minut, a z wykorzystaniem zewnętrznych narzędzi np. MSSQL potrafi wycofać pojedyńcze transakcje wykonane na bazie czyli np. przypadkowego DELETE'a
- oczywiście banalne pytanie, czy Clipper potrafi obsłużyć bazę większą niż 2 GB ? Jeśli nie może przerobić by go nie było trudno, ale właśnie...trzeba by go przerobić, dostosować, żeby mógł wykorzystać możliwości współczesnego sprzętu
- no i ostatnie ważne pytanie - integracja w środowisku wieloplatformowym - współczesne komercyjne bazy mają narzędzia replikacji, mirroringu automatycznego powielania informacji - nie tylko pomiędzy własnymi środowiskami/instancjami, ale np. MSSQL potrafił by odczytać, zapisać dane do np Oracle (np. umożliwia replikację) czy pewnie nawet Clippera (przez linked server).

Pozatym nawiązując do wątku: w dzisiejszych czasach baza danych nie jest workiem na dane. Potrafi wiele / bardzo wiele - "z pudełka" programiści dostają potężne narzędzia - jak np. Reporting Services. No i oczywiście są jeszcze CLRy i stored procedures.
Doświadczenie w rozwiązaniach klasy Enterprice mam. I jeśli chodzi o bazy danych - zasada Keep It Simple and Sloppy sprawdza się znakomicie ! Nie upierałbym się w zamykaniu całej logiki biznesowej w bazie danych. To co da się zrobić łatwo i szybko w T-SQLu powinno być zamknięte w "storkach". To co nie da się łatwo obsłużyć, niech się przetwarza w kodzie, ale na zewnątrz bazy danych. CLR to już jest kompromis...aby dało się wykonać bardzo złożone rzeczy, których przy implementacji silnika bazodanowego uwzględnić się nie dało. Co do zasady CLR nie powinno się stosować - inaczej konieczność zastosowania CLR w bazie - projektanci powinni w projekcie aplikacji mocno uzasadnić (tym że zrobić inaczej się tego nie da).
Oczywiście to tylko moja skromna opinia.

Temat: CLR Ucieczka od SQL SERVER

Panie Stanisławie - rękami i nogami podpisuję się pod tym co napisał Jarosław. Lepiej bym tego nie ujął.

Od siebie dodam że oczywiście nie jestem specem od baz plikowych, miałem z nimi nico styczności przy drobnych robótkach dla geodetów. Ale to stare dzieje.
Oczywiście panienka z okienka to nie ekspert, ale chodzi o pewne postrzeganie spraw. Długie doświadczenie z jakąś technologią o dużym spektrum zastosowań sprawia że w zasadzie potrafimy zrobić nią wszystko. Znam człowieka co nigdy nie da sobie wmówić, że są lepsze alternatywy od PHP.
Są tacy co do upadłego bronią Linuxa, ja często do upadłego bronię Microsoftu i jego rozwiązań.
Jak już pisałem - nowe technologie to nowe możliwości. Mądre z nich korzystanie prowadzi do sukcesu. A nawet jeżeli coś działa szybciej w jednej technologii niż w drugiej - to tylko jedna z cech którą należy brać pod uwagę przy planowaniu architektury. Jest jeszcze skalowalność, bezpieczeństwo, testowalność, zarządzalność, support, czas realizacji zadania. Świat nie idzie ślepo w "nowinki" tylko stara się utrzymać balans tych parametrów.
Taka jest moja opinia i moje doświadczenie - ale jak wiadomo - punkt widzenia zależy od punktu siedzenia, i o tym też warto pamiętać.

Temat: CLR Ucieczka od SQL SERVER

Witam po małej przerwie. Dalej jednak będę się drażnił z wszystkimi obrońcami SQl'a i jak do tej pory proszę to traktować z przymrużeniem oka. Sam już dawno "zapomniałem" o Clipperze i FOX'ie. Od około 10 lat pracuję też /między innymi/ na SQL'u. Na własne potrzeby mam też zainstalowanego SQL'a w swojej prywatnej domowej sieci i z przykrością przyznaję, ale sobie go chwalę.

I tyle podlizywania się wszystkim "ortodoksom" SQL'a.

"Śmiechu warte" są stwierdzenia /pytania/ czy Clipper odtworzy 2GB bazę. Panie Jarku, Clipper pod tym względem nia ma żadnych ograniczeń poza przestrzenią dyskową. Dla wyjaśnienia Clipper to kompilator wyspecjalizowany na pisanie programów do obsługi tabel baz danych typu *.dbf. Taki Basic dla baz danych.
Tabela bazy danych miała oczywiście ograniczenia jak 256 pól, ilość rodzaji pól i ilość rekordów w tablicy - 1 miliard. Tabele Clippera miały i mają jedną fantastyczną rzecz, patent na bardzo szybkie indeksowanie. Między
innymi dla tego Microsoft kupił FOX'a który korzystał właśnie z tego samego mechanizmu. Pozatym w Clipperze nie ma mowy o żadnych ograniczeniach typu: licencja na "usera", procsy, połączenia i zachody słóńca. Ilu kolesi się podłączy i jakie uprawnienia im nadamy decyduje programista. Co do wycofania tranzakcji to Clipper też ma taki mechanizm. Co do sprzętu nie ma żadnego problemu. Dotyczy to też środowiska. Sam SQL też czyta te bazy. Jeśli chodzi o backupy w locie też żaden problem. Po prostu wszystkie bazy od 20-30 lat mają ten problem rozwiązany jako problem podstawowy. Reszta to tylko w jakim krawacie wystąpie, ale efek zawsze ten sam. Oczywiście sam Clipper nie wyeksportuje plików do innych formatów. Procedury takie trzeba by było napisać, co nie jest żadnym problemem. Ale wszystkie współczesne bazy jako podstawę mają import i export baz dbf i wyższych. Excel też czyta i exportuje takie bazy. Więc problemu nie ma.

Panie Sławku, co Pan trzyma w ręce i czy Pan to pije lub wącha. Jak to świat nie idzie ślepo w kierunku nowinek. Niech Pan rozejrzy się dookoła. Ktoś kiedyś powiedział: gdyby ludzie nie kupowli rzeczy im niepotrzebnych to kapitalizm by zbankrutował. To tak jak z procesorami 64bit, a rozkazy języka maszynowego dalej są 8 bitowe i parę 16 bitowych. No ile tego można wymyśleć.
8 bit to 256 rozkazów. Nie wyobrażam sobie by ich wymyślono chociażby parę tysięcy. Zresztą najszybsze procesory to procesory typu RISC, króre wykonują tylko skrócona listę rozkazów.

Panowi, jesteście szaleni.

Pozdrowienia i miłego dnia.

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
To tak jak z procesorami 64bit, a rozkazy języka maszynowego dalej są 8 bitowe i parę 16 bitowych. No ile tego można wymyśleć.

64 bity są po to, żeby móc adresować więcej pamięci, a nie wykonywać coraz więcej rozkazów.

Pozdrawiam.

Temat: CLR Ucieczka od SQL SERVER

"Śmiechu warte" są stwierdzenia /pytania/ czy Clipper (..)

Panowi, jesteście szaleni.

Pytanie nie jest oznaką szaleństwa, bardziej dociekliwości - jesli odpowiedzi są oczywiste...proszę o wyrozumiałość - jak pisałem Clipera nie znam.

Gdyby problem np. backupów wszystkie bazy miały rozwiązany w sposób zadawalający - nie pisałbym o tym.

Temat: CLR Ucieczka od SQL SERVER

Jarosław Kędzierski:

"Śmiechu warte" są stwierdzenia /pytania/ czy Clipper (..)

Panowi, jesteście szaleni.

Pytanie nie jest oznaką szaleństwa, bardziej dociekliwości - jesli odpowiedzi są oczywiste...proszę o wyrozumiałość - jak pisałem Clipera nie znam.

Gdyby problem np. backupów wszystkie bazy miały rozwiązany w sposób zadawalający - nie pisałbym o tym.

Ale Pan Stanisław pisze przecież półprawdy ...
1. Obsługa transackji w Clipperze to namiastka przetwarzania transakcyjnego i nie działa jak należy (ma chyba ograniczenie do alokowania 255 rekordów czy coś takiego).
2. Backup w czasie gdy baza jest używana, nie daje gwarancji spójności danych, po jego otworzeniu można się zdziwić, że coś zostało "urwane" :)
3. Mógłbym jeszcze długo pisać co jest, a nie działa jak należy, ale to nie ma sensu. Myslę, że Pan Stanisław ma dużo wolnego czasu i tak się zabawia nostalgiczną dyskusją dotyczącą starych i mało już użytecznych technologii.
pozdrawiamROMAN WILK edytował(a) ten post dnia 19.08.11 o godzinie 12:04

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
Panie Sławku, co Pan trzyma w ręce i czy Pan to pije lub wącha.

Wygląda na to, że raczej wącha :)

miłego dnia

Temat: CLR Ucieczka od SQL SERVER

Ten temat to flame najczystszej postaci, ale co mi tam...

Logika w bazie danych ma jedną wadę - maintenance (analiza kodu, rozbudowa, debug, wersjonowanie).

Z drugiej strony jest to jeden z najszybszych sposobów przetwarzania bazy SQL.

Najlepiej założyć że są trzy warstwy:
0) dostęp do danych
1) logika biznesowa
2) warstwa prezentacji

... i nie mieszać ich.
A że implementuje i debuguje się łatwiej programy klasyczne (tu CLR) niż T-SQL to chyba oczywiste...

W PostgreSQL jest trochę inaczej, bo tam można w bazie programować w wielu różnych językach - z tego co się orientuję.
Jeśli do wyboru jest tylko C# i T-SQL to chyba nie ma się co spierać - w bazie zostawić tylko wartstwę (0) i koniec.Piotr L. edytował(a) ten post dnia 27.09.11 o godzinie 19:27

Temat: CLR Ucieczka od SQL SERVER

dla jasności CLR w MSSQL-u można pisać w dowolnym języku .NET pod warunkiem spełnienia pewnych rygorystycznych zasad
http://msdn.microsoft.com/en-us/library/ms403273.aspx

więc nie ma tak że wszystko wolno

Temat: CLR Ucieczka od SQL SERVER

A ja całe życie myślałem że 8 bit, 16 bit, 32 bit i 64 bit w procesorach zawsze odnosiło sie do magistrali danych, a nie do magistrali adresowej. No cóż ... człowiek uczy się całe życie. Dzieki za włączenie sie do dyskusji.

Pozdrowionka.

Łukasz Kurowski:

Stanisław Kozłowski:
To tak jak z procesorami 64bit, a rozkazy języka maszynowego dalej są 8 bitowe i parę 16 bitowych. No ile tego można wymyśleć.

64 bity są po to, żeby móc adresować więcej pamięci, a nie wykonywać coraz więcej rozkazów.

Pozdrawiam.

Temat: CLR Ucieczka od SQL SERVER

Jeszcze raz podkreślam, że na wszystkie moje wypowiedzi proszę patrzeć z przymrużeniem oka. Proszę nie brać sobie do serca moich zwrotów. Nie jest moim zamiarem nikogo obrażać. Chce po prostu rozwinąć dyskusję w kierunku czy aż tak potężne narzędzie, jakim jest SQL, zawsze nam jest potrzebne. Wiem, że momentami plotę trzy po trzy i niektóre wypowiedzi naciągam. Nie obrażę się, gdy ktoś napisze, że takiego durnia jeszcze nie widział... podyskutujemy.
Wiem z ponad 20-letniego doświadczenia, że informatycy to ludzie pogodni i są obdarzeni dużą dozą humoru, w przeciwieństwie do wielu dyrektorów, prezesów i wielu innych zadufanych w sobie władców i panów.

Z poszanowaniem dla wszystkich uczestników dyskusji, ten co wszystkie rozumy pozjadał

Kozłowski Stanisław

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
Jeszcze raz podkreślam, że na wszystkie moje wypowiedzi proszę patrzeć z przymrużeniem oka. Proszę nie brać sobie do serca moich zwrotów. Nie jest moim zamiarem nikogo obrażać. Chce po prostu rozwinąć dyskusję w kierunku czy aż tak potężne narzędzie, jakim jest SQL, zawsze nam jest potrzebne. Wiem, że momentami plotę trzy po trzy i niektóre wypowiedzi naciągam. Nie obrażę się, gdy ktoś napisze, że takiego durnia jeszcze nie widział... podyskutujemy.
Wiem z ponad 20-letniego doświadczenia, że informatycy to ludzie pogodni i są obdarzeni dużą dozą humoru, w przeciwieństwie do wielu dyrektorów, prezesów i wielu innych zadufanych w sobie władców i panów.

Myślę, że nikt się nie obraża. Chociaż pewien Pan co kiedyś WC Kwadrans prowadził to by się obraził za „Wąchanie” :)
Ziółka na rozjaśnienie umysłu czasem wpływają lepiej niż czarne ziarenka na wrzody żołądka.
Dla dociekliwych: http://www.yerbamarket.com/
Co do szaleństwa – szalonym jest człowiek co spędza z komputerem więcej czasu niż z ludźmi i gada godzinami o abstrakcyjnych bytach które powstają jak grzyby po deszczu i jeszcze szybciej znikają.
Tak jestem fanatykiem rozwiązań Microsoftu – coś w życiu trzeba lubić poza sobą ;)
Mówiąc o tym że świat nie idzie ślepo za nowinkami miałem na myśli podzbiór technologii informatycznych, nie koniecznie zabawek dla dzieci mówiącymi w 4 językach.
W dzisiejszych czasach biznes potrzebuje rozwiązań przede wszystkim szybko i tanio – jak się trafi do środowiska gdzie biznes sponsoruje development to niema tłumaczenia, że chcemy przyśpieszyć działanie aplikacji więc potrzebujemy dodatkowego miesiąca na kodowanie. Teraz gdybym w MFC miał pisać to co robię w C# to może i dało by się zrobić to samo - ale chyba bymnerwicy dostał, ale pewneie nikt nie chciał by za projekt płacicć bo za długo i za mało.

Może aparat cyfrowy nie zrobi lepszego zdjęcia niż analogowy, ale zdecydowanie mniej się trzeba z nim dziubać. A są i tacy co używają pudełka z dziurką do robienia zdjęć i są szczęśliwi.

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
Chce po prostu rozwinąć dyskusję w kierunku czy aż tak potężne narzędzie, jakim jest SQL, zawsze nam jest potrzebne.

Idąc tym tropem zaraz zaczniemy kwestionować zasadność korzystania z tak potężnych narzędzi jak np. dzisiejsze komputery i ich systemy operacyne. Przecież też wykorzystujemy tylko mały zakres ich możliwości, a jednak każdy z nas ma jakiś w domu. I tak dalej i tak dalej.

Odpowiedź oczywiście leży gdzieś pomiędzy słowami "standaryzacja" i "optymalizacja kosztów". Tylko każdy to wie, więc o czym tu rozmawiać?Bartosz Ślepowronski edytował(a) ten post dnia 20.08.11 o godzinie 22:12

Temat: CLR Ucieczka od SQL SERVER

Witam - bardzo fajna rzeczowa wypowiedź!
Pozdrawiam

Jarosław Kędzierski:

Stanisław Kozłowski:
Sam język zapytań wypisz wymaluj cały FOX.
Więc pytanie brzmi: w czy jest SQL lepszy od FOXA lub nawet Clippera obu sprzed 20 lat.

Aaa...w zasadzie nie powinienem się wypowiadać. Bo przecież nie znam Clippera. Ale...

1. że SQL "działa" "mniej więcej" tak samo na wszystkich bazach już od lat - chwała za to standaryzacji ! Choć do dziś niestety różnice się zdarzają.
2. Dyskusja przypomina mi tą, którą toczyłem gdzieś ostatnią, gdzie udowadniać mi przyszło wyższość komercyjnego MS-SQL na darmowym MySQL. I co się okazało ? W typowych przypadkach, w zasadzie bazy działają podobnie - ale diabeł tkwi w szczegółach:
- we współczesnych komercyjnych bazach nie stanowi problemu wykonanie jej backupu przy zachowaniu ciągłości pracy. Banalne ? A jednak już np. w MySQL jest to "jakiś" problem. A jak było w Cliperze ?
- współczesne komercyjne bazy danych dają możliwość odtworzenia historycznego stanu bazy danych, np sprzed 10 minut, a z wykorzystaniem zewnętrznych narzędzi np. MSSQL potrafi wycofać pojedyńcze transakcje wykonane na bazie czyli np. przypadkowego DELETE'a
- oczywiście banalne pytanie, czy Clipper potrafi obsłużyć bazę większą niż 2 GB ? Jeśli nie może przerobić by go nie było trudno, ale właśnie...trzeba by go przerobić, dostosować, żeby mógł wykorzystać możliwości współczesnego sprzętu
- no i ostatnie ważne pytanie - integracja w środowisku wieloplatformowym - współczesne komercyjne bazy mają narzędzia replikacji, mirroringu automatycznego powielania informacji - nie tylko pomiędzy własnymi środowiskami/instancjami, ale np. MSSQL potrafił by odczytać, zapisać dane do np Oracle (np. umożliwia replikację) czy pewnie nawet Clippera (przez linked server).

Pozatym nawiązując do wątku: w dzisiejszych czasach baza danych nie jest workiem na dane. Potrafi wiele / bardzo wiele - "z pudełka" programiści dostają potężne narzędzia - jak np. Reporting Services. No i oczywiście są jeszcze CLRy i stored procedures.
Doświadczenie w rozwiązaniach klasy Enterprice mam. I jeśli chodzi o bazy danych - zasada Keep It Simple and Sloppy sprawdza się znakomicie ! Nie upierałbym się w zamykaniu całej logiki biznesowej w bazie danych. To co da się zrobić łatwo i szybko w T-SQLu powinno być zamknięte w "storkach". To co nie da się łatwo obsłużyć, niech się przetwarza w kodzie, ale na zewnątrz bazy danych. CLR to już jest kompromis...aby dało się wykonać bardzo złożone rzeczy, których przy implementacji silnika bazodanowego uwzględnić się nie dało. Co do zasady CLR nie powinno się stosować - inaczej konieczność zastosowania CLR w bazie - projektanci powinni w projekcie aplikacji mocno uzasadnić (tym że zrobić inaczej się tego nie da).
Oczywiście to tylko moja skromna opinia.

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
A ja całe życie myślałem że 8 bit, 16 bit, 32 bit i 64 bit w procesorach zawsze odnosiło sie do magistrali danych, a nie do magistrali adresowej.

Zgadza się, tylko już od wielu lat producentom procesorów jakoś się klei stosowanie jednakowej szerokości magistrali danych i adresowej. Im mniej cudaków typu PAE, tym architektura prostsza. Czasy Z80 już nie powrócą ;)...
http://pl.wikipedia.org/w/index.php?title=Plik:Z80_arc...

Pozdrawiam.

Temat: CLR Ucieczka od SQL SERVER

Chociaż dyskusja miała już miejsce jakiś czas temu, to postanowiłem coś w temacie napisać.

Pisałem i w clipperze i innych starszych systemach bazodanowych, ale od wielu lat programuję w TSQLu a czasami używam CLRów głównie w C#.

Udział CLRu oceniam na nie więcej niż 5% i tylko w celu stworzenia szybkich specjalistycznych funkcji i nie dlatego, że nie da się czegoś zrobić w TSQLu, tylko dlatego, że niektóre rozwiązania mogą być szybsze.

Tytułowy problem to jednak jest chyba coś innego. Jeżeli ktoś zna jedej język (C#) to będzie forsował CLR zamiast poduczyć się TSQLa. Niektórzy używają TSQL i unikają CLR co też w pewnych przypadkach może być niewłaściwe.

Co do wydajności - nie używajcie kursorów (cursor-ów) - jest przecież CTE. A co do wydajności proponuję zacząć od dobrej struktury baz danych, kluczy, indeksów, constraintów, triggerów etc. (ale banały) - a wtedy i kod będzie bardziej zwięzły.

Mój wniosek - unikajcie CLR, poznajcie mocne strony SQLa

Temat: CLR Ucieczka od SQL SERVER

Krzysztof Gil:
Chociaż dyskusja miała już miejsce jakiś czas temu, to postanowiłem coś w temacie napisać.

Co do wydajności - nie używajcie kursorów (cursor-ów) - jest przecież CTE.

Ale o co chodzi z tym CTE zamiast kursorów? Cursorów używa się kiedy potrzebujemy coś przeprocesować row-by row (choć często można je zastąpić za pomocą cross apply/ outer apply) bądź pętli while i odpowiedniej logiki, a CTE to tymczasowy widok, przy czy mozna sobie robić za jego pomocą hierarhiczność, ale jest procesowany jak dataset a nie row by row

Odnośnie SQL CLR to prosta zasada:
"If You get confused - use T-SQL"Szymon P. edytował(a) ten post dnia 26.09.11 o godzinie 23:17

Temat: CLR Ucieczka od SQL SERVER

Ale o co chodzi z tym CTE zamiast kursorów? Cursorów używa się kiedy potrzebujemy coś przeprocesować row-by row (choć często można je zastąpić za pomocą cross apply/ outer apply) bądź pętli while i odpowiedniej logiki, a CTE to tymczasowy widok, przy czy mozna sobie robić za jego pomocą hierarhiczność, ale jest procesowany jak dataset a nie row by row

CTE to nie tylko widok z możliwością rekurencji. W poprzednim roku zajmowałem się usuwaniem kursorów z procedur w średniej wielkości bazach danych (po 300-700GB) i proszę mi wierzyć lub nie - nie został ani jeden kursor. A przetwarzań typu row-by-row było i jest bardzo dużo.
Jężeli wykorzystamy CTE, cross apply, typy tablicowe, funkcje rangujące, konstrukcje (VALUES ( wartości ) AS widok(pola)) itp. to z dużą korzyścią wydajnościową można przepisać wszystkie kursory i większość pętli.

Pętli WHILE też staramy się nie używać - można zbudować inne - dużo wydajniejsze konstrukcje (w tym roku już więcej jak połowa z ponad 500 procedur z pętlami uległa radykalnej przebudowie).Krzysztof Gil edytował(a) ten post dnia 27.09.11 o godzinie 11:38

Temat: CLR Ucieczka od SQL SERVER

Krzysztof Gil:

Ale o co chodzi z tym CTE zamiast kursorów? Cursorów używa się kiedy potrzebujemy coś przeprocesować row-by row (choć często można je zastąpić za pomocą cross apply/ outer apply) bądź pętli while i odpowiedniej logiki, a CTE to tymczasowy widok, przy czy mozna sobie robić za jego pomocą hierarhiczność, ale jest procesowany jak dataset a nie row by row

CTE to nie tylko widok z możliwością rekurencji. W poprzednim roku zajmowałem się usuwaniem kursorów z procedur w średniej wielkości bazach danych (po 300-700GB) i proszę mi wierzyć lub nie - nie został ani jeden kursor. A przetwarzań typu row-by-row było i jest bardzo dużo.
Jężeli wykorzystamy CTE, cross apply, typy tablicowe, funkcje rangujące, konstrukcje (VALUES ( wartości ) AS widok(pola)) itp. to z dużą korzyścią wydajnościową można przepisać wszystkie kursory i większość pętli.

Pętli WHILE też staramy się nie używać - można zbudować inne - dużo wydajniejsze konstrukcje (w tym roku już więcej jak połowa z ponad 500 procedur z pętlami uległa radykalnej przebudowie).

kursor jest fajny jak blokowo przetwarzasz jakieś operacje np. masz procedurę wykonującą czynność w bloku, ale parametryzujesz ją już za pomocą wartości z kursora, bardzo przydatne w przyspieszaniu operacji insert/update

Temat: CLR Ucieczka od SQL SERVER

co do uzywania samego TSQL'a nie moge sie zgodzic ze stwierdzeniem zeby uzywac go tam gdzie sie da.
W moim przypadku TSQL jest wielokrotnie wolniejszy od C# (CTE tez nie pomagalo, indexy , index covering itp rozwiazania).
C# i CLR okazaly sie najlepsze.

Zawsze jesli chodzi o tworzenie pewnych rozwiazan nalezy przeanalizowac wszystkie za i przeciw (chociazby CLR i restore bazy danych a db_owner :) - ot takie ciekawostki od M$ )