Grzegorz Łyp

Problem Solver

Wypowiedzi

• Wszystko
• Tylko fora
• Tylko mikroblogi

• 
  Wpis na mikroblogu Własna firma. Odkrywamy przepisy na sukces.

  Witam :) I dziękuję za zaproszenie. Od 10 lat jestem na rynku tworzeniem oprogramowania, a od roku kieruję zespołem deweloperów. Chętnie pomogę w doborze technologii oraz szacowaniu kosztów budowania oprogramowania każdego rodzaju.

  Witam :) I dziękuję za zaproszenie. Od 10 lat jestem na rynku tworzeniem oprogramowania, a od roku kieruję zespołem deweloperów. Chętnie pomogę w doborze technologii oraz szacowaniu kosztów budowania oprogramowania każdego rodzaju.

  • 18.07.2012, 20:08
  • Skomentuj

  • Odpowiedz...

    
• 
  Wpis na grupie Bazy Danych w temacie CLR Ucieczka od SQL SERVER

  17.08.2011, 05:22

  Zasadniczo nie powinno się używać CLR tam, gdzie możliwy jest do napisania odpowiednik TSQL. Należy pamiętać, że CLR jest zastąpieniem mechanizmu Extended Procedure, a zapewne nie wielu ludzi pisało kiedyś w tym mechaniźmie logikę biznesową. Oczywiście pisanie CLR jest o wiele łatwiejsze niż Extended Procedure, co prowadzi do naiwności, że warto często tą technologię stosować. Moim zdaniem mechanizmy zakotwiczone w CLR powinny stanowić niskopoziomowe funkcje, które dają szeroki wachlarz możliwości. Przykładami są takie funkcje jak: CRC32, czytanie lub zapis do pliku, konwersja kodowania, wyliczanie możliwych kodowań znaków (przydatne w XML) itp. Logika biznesowa napisana w CLR powoduje zamknięcie kodu, co z jednej strony jest zaletą, a z drugiej strony wadą. Pamiętajmy jednak, że kod TSQL można też zablokować do odczytu przez innych. Pozostaje wydajność i tutaj warto pamiętać, że wiele nietypowych lub wręcz uważanych za nieoptymalne rozwiązań daje dobre efekty. Takie elementy jak zapytania zagnieżdżone itp. sprawdzają się, przy odpowiednim użyciu w bardziej złożonych obliczeniach, a mechanizm optymalizacji zapytań MS SQL pozwala na szybkie ich działanie w oparciu o logikę zbiorów.