GoldenLine
Zaloguj się
Sławomir Marcjański

Sławomir Marcjański Programista /
Ethical Hacker

Temat: CLR Ucieczka od SQL SERVER

Witam,

Ponieważ "pływam" w dwóch światach - jestem programistą .Net ale również zajmuję się bardziej zaawansowaną bazodanówką czuję się rozdarty gdy spotykam się z sytuacją gdzie developerzy naciskają na używanie CLR-a.
Wygodne prawda? Znasz C#, nie trzeba robić tasiemców SQL-owych, zapominamy o optymalizacjach, zapominamy o języku T-SQL (który do biznesowej logiki jest dość ciężki) i jedziemy z C# jak w kliencie.
Z drugiej strony - dla bazodanowca to tragedia - brak możliwości zeskryptowania / poprawki, analizy planu wykonania takiego na przykład USP w CLR. Dodatkowo utrudnienia przy deployu aplikacji i skryptów, restorach bazy no i zmiany w konfiguracji serwera. Obiekty bazodanowe które stają się czarną skrzynką i bez Visual Studio ani rusz.

I teraz pytanie - jak uważacie - pozwalać na takie działania czy je limitować.
Jak dla mnie to fajne że można logikę biznesową bardziej skomplikowaną napisać w C# (bo prościej i zwięźlej), ale czy takie rzeczy nie powinny lądować do serwisu bardziej niż do bazy danych?

Gdzie tu szukać kompromisu?
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

limituj tylko do tego czego nie możesz zrobić w T-SQL, albo inii już nie zrobili np. zaawansowane funkcje matematyczne. Inne gadżety można wykonać w T-SQL-u w sposób w miarę prosty a przeważnie szybszy
Link do wypowiedziLink
Sławomir Marcjański

Sławomir Marcjański Programista /
Ethical Hacker

Temat: CLR Ucieczka od SQL SERVER

Niestety to nie taka jasna granica jest.
Zasadniczo chodzi o kod biznesowy więc trochę iteracji, trochę logiki, trochę zaciągania i przetwarzania danych.
No i zasadniczo wszystko to da się zrobić w T-SQL tylko, że wychodzą z tego tasiemce na tysiące linii (tu bonus dla zwolenników CLR), ten sam kod w C# zajmie kilkaset linii i jest to dużo mniejszy kłopot...
Nie mniej często CLR to ucieczka w C# od T-SQL. Powiedzmy sobie szczerze - przeciętny developer zna T-SQL tak sobie więc dając mu CLR do ręki powstaną wykwity różnych funkcjonalności które zastąpią te już istniejące w SQL Serverze... no ale to C# będzie.
Problem jest głębszy - taki USP CLR powinien zachowywać się jak ten klasyczny (jeżeli chodzi o wejście, wyjście i wyjątki), ale C# pozwala na wprowadzanie swoich patentów i tu znowu - powstaje nowa rodzina obiektów które są jakoś SQL-owo upośledzone.
Ale ja z kolei mam opór do CLR-a jak inni do T-SQL może dlatego mnie to tak męczy.
Link do wypowiedziLink
Tomasz Andrzejewski

Tomasz Andrzejewski PROGRAMMING ENGINEER
(DELPHI, SQL)

Temat: CLR Ucieczka od SQL SERVER

Niestety TSQL nie zawsze jest szybszy (nawet mam wrazenie ze ogolnie wolniejszy).
Ja dokonuje wpisu ok 1000 rekordow z ich wyliczeniem (plan amortyzacji srodka trwalego [nie tylko metoda liniowa]) w czase 380 ms.
W TSQL (cursor) nie ma szans na taka wydajnosc
Link do wypowiedziLink
Grzegorz Kmiecik

Grzegorz Kmiecik Inżynier ds.
Testowania i
Oprogramowania,
Intel Technolog...

Temat: CLR Ucieczka od SQL SERVER

Zależy od podejścia, można wystawić procedury składowane w bazie i korzystać tylko z odwołań do nich - bardzo ciężkie w debugowaniu- sql to plain text, więc jeżeli nagle trzeba przebudować logikę biznesową (np. dodać kolumnę) poprawianie tego może zająć trochę czasu, szczególnie testowanie.

Ja jako developer używam Entity Framework (4.0), korzystając z zapytań linq, jestem w stanie szybko reagować na zmiany, jeżeli nawet ktoś "cichu" zmienił strukturę bazy danych a mój kod nie uwzględnia takich zmian to dostanę błąd kompilacji i wiem gdzie szukać błędów.

Oczywiście wydajne zapytania w linq też trzeba umieć pisać i na to potrzeba przeczytać z jedną dobrą książkę.
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Ja jestem zwolennikiem pisaniem bezpośrednio w SQL jeśli to możliwe. Entity jest wygodne ale ma swoje ograniczenia np. FullTextSearch. CLR z kolei stosowałem w rozwiązaniach gdzie SQL nie wystarczał z powodu konieczności wykonywania skomplikowanej logiki biznesowej systemu. Poza tym potem były problemy z jego utrzymaniem i debugowaniem. Poza tym CLR jest wolniejszy niż zwykły SQL.

Jeśli chodzi o kompromis to zostałbym przy SQLu jak tylko długo się da.
Link do wypowiedziLink
Marek Jarocki

Marek Jarocki Programista, Asseco
Business Solutions
S.A.

Temat: CLR Ucieczka od SQL SERVER

Na początku należałoby zadać sobie pytanie, które z obszarów systemu są niezmienne, a które raczej będą ewaluowały.
O ile w tym pierwszym przypadku koszt obsługi CLR nie jest duży, to w drugim (przy częstych zmianach biznesowych) może być to co najmniej uciążliwe. Osobną kwestią jest model podnoszenia wersji systemu u klientów - czy jest to głównie przekazanie skryptów SQLowych czy może za każdym razem wysyłane są nowe wersje aplikacji.
Ja osobiście logikę biznesową pakuję do SQL-a, CLRa używam tylko gdy jestem na to skazany, np. do wywoływania WebService.
Link do wypowiedziLink
Grzegorz Łyp

Grzegorz Łyp Problem Solver

Temat: CLR Ucieczka od SQL SERVER

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.
Link do wypowiedziLink
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: CLR Ucieczka od SQL SERVER

@CLR vs tysiące linii kodu TSQL

Tysiące linii kodu w TSQL = źle napisany kod lub coś czego nie trzeba robić po stronie bazy. Tak z doświadczenia.

@Kursor do liczenia amortyzacji

Pierwsza zasada SQL - nie używaj kursorów. Jasne, czasem nie ma innej sensownej możliwości, ale w większości przypadków okazuje się, że kursor można wywalić. I nagle okazuje się, że TSQL jednak jest szybki.

Generalnie, czy jest sens zadawać takie pytania? Jest jakiś problem i jakiś dostępny skillset żeby go rozwiązać. Wybieramy rozwiązanie które w ramach tego skillsetu rozwiąże problem najefektywniej. Czy to będzie CLR czy TSQL - nie ma większego znaczenia. Jasne, fajnie byłoby gdyby developer napisał super wydajny kod SQL, ale jeśli nie potrafi to przecież nie będziemy czekać kilku miesięcy (lat?) aż się nauczy, nie?
Link do wypowiedziLink
Marcin Badtke

Marcin Badtke Administrator Baz
Danych, Citibank
Europe plc

Temat: CLR Ucieczka od SQL SERVER

Baza danych jest skomplikowanym produktem o wszechstronnych możliwościach stworzonym aby zabezpieczyć i wydajnie zarządzać naszymi danymi. Moim zdaniem _WSZYSTKO_ co tylko można powinno być zawarte w bazie danych: security aplikacji, logika biznesowa, przetwarzanie masowe, itp. Baza danych istnieje właśnie po to aby robić to najlepiej i najwydajniej jak można. Żaden język programowania jej tutaj nie zastąpi. To, że ktoś twierdzi, że przy pomocy bazy danych nie da się czegoś zrobić z danymi znaczy, że po prostu nie zna tej bazy danych (w sensie motoru). Na zewnątrz bazy danych zostawiłbym jedynie warstwę wizualizacji danych.
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Marcin Badtke:
Baza danych jest skomplikowanym produktem o wszechstronnych możliwościach stworzonym aby zabezpieczyć i wydajnie zarządzać naszymi danymi. Moim zdaniem _WSZYSTKO_ co tylko można powinno być zawarte w bazie danych: security aplikacji, logika biznesowa, przetwarzanie masowe, itp. Baza danych istnieje właśnie po to aby robić to najlepiej i najwydajniej jak można. Żaden język programowania jej tutaj nie zastąpi. To, że ktoś twierdzi, że przy pomocy bazy danych nie da się czegoś zrobić z danymi znaczy, że po prostu nie zna tej bazy danych (w sensie motoru). Na zewnątrz bazy danych zostawiłbym jedynie warstwę wizualizacji danych.

polecam pisanie w T-SQL-u czegoś takiego: http://numerical.codeplex.com/
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Trochę na przekór i przewrotnie, ale zarazem bardzo poważnie.

Zastanawiam się na co komu SQL i cała ta reszta. Swoją przygodę z programowaniem baz danych rozpocząłem jakieś 20 lat temu, kiedy informatyką "rządzili jeszcze hobbiści i pasjonaci". Najcudowniejszy program do zarzadzania bazami to Clipper Summer 87'/do dzisiaj trzymam pudełko z oryginalnymi dyskietkami i licencją/. Z mojej praktyki wynika, że w zasadzie wszystko co potrzeba w bazach tam jest. Wszystko po Cliperze, to komercja dla "podziwiaczy", profesorskiego "bełkotu" i "leni" progrmistów. Microsoft wykupując "normalne" bazy danych i przebudowując je według chorej wyobraźni programistów Microsoftu, dobrowadził do dziwacznej sytuacji. Programiści nie powinni się zastanawiać jak napisać program od strony używanych narzędzi, tylko powinni skupić się na tym, czego od niego oczekuje odbiorca programu. A tam zawsze jest tyko dwa dodać dwa i jeszcze parę podstawowych działń matematycznych. No oczywiści trzeba to zapisać na dysku, wysłać na ekran i drukarkę. Koniec kropka. Czy zrobić to tak czy siak, jest więc tylko czysto teoretycznym rozważaniem. Może nawet i akademickim.
Ustosunkowując się do innych wypowiedzi.
Poważna baza i program do jej zarządzania, nawet ten dwa dodać dwa, powinien być zwsze programem zamkniętym. Jeśli ktoś może zmienić strukturę bazy samowolnie bez wiedzy pozostałych, należy natychmiast zwolnić "kierownika robót", a programiście dożywotnio zakazać programowania czego kolwiek, nawet telewizora. Baza danych nie jest skomplikowanym produktem. Dopiero baza danych w wydaniu współczesnym jest idiotycznym produktem. Sama baza danych to tylko sformatowany plik tekstowy i do jego obslugi wystarczy przysłowiowe 10 komend. Ja osobiście odstawiłbym te wszystkie wynalazki i problem zapisał właśnie w pliku txt /nawet do użytku w sieci i na serwerze/ przy pomocy np. VB.Net.

Jeszcze jedno, nie da się porównać szybkości baz: Clipper, Fox z bazą SQL jeśli chodzi szybkość odpowiedzi na zapytanie i ich prace w sieci. Te pierwsze to F1 w starciu z Fiatem 126p.

Rozumię, że postawiony problem to "zwykła podstępna prowokacja" i "woda na młyn odwetowców".
Link do wypowiedziLink
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Temat: CLR Ucieczka od SQL SERVER

Witam,
również od 20 lat zajmuję się projektowaniem / programowaniem (dokładnie systemu klasy ERP/MRP/CRM/HR). Początki projektu to lata 90'te i tabele Paradox (do dziś mnie straszy plik PDOXUSRS.NET). Od 10 lat to SQL i Firebird (obecnie ver 2.5 bardzo dobra i niedoceniana baza
danych, ale oczywiście gorsza od Oracle :)). SQL i bazy transakcyjne są o niebo lepsze od "destopowych" wynalazków. Zresztą bazy, o których piszesz zostały właśnie tak zaprojektowane, aby pracować lokalnie (tzn. program i baza na tej samej maszynie). Ich rozwój nad współdzieleniem danych (nie wspominając o lokowaniu rekordu, a nie pola jak SQL) to tylko były kolejne nieudolne próby ich rozwoju. To o czym piszesz odnośnie wydajnonści, to też raczej wyssane z palca. Dobrze zaprojektowana baza SQL jest od pewnej progowej wielkości zdecydowanie szybsza od desktopowej bazy danych (kwestia strojenia i konstrukcji), natomiast desktopowa od pewnej brzegowej wartości rekordów po prostu przestaje działać.

pozdrawiam
EDIT
literówki ...ROMAN WILK edytował(a) ten post dnia 17.08.11 o godzinie 18:11
Link do wypowiedziLink
Sławomir Marcjański

Sławomir Marcjański Programista /
Ethical Hacker

Temat: CLR Ucieczka od SQL SERVER

No i mamy całe spektrum odpowiedzi :).
A więc do dzieła:
@Szybkość:
Nie wątpię że do przetwarzania logiki biznesowej CLR jest szybszy - w sumie wykonuje się jako kod platformowy nie jako skrypt więc ma do tego prawo. Jednak mi się wydaje że podobny efekt i większą skalowalność osiągniemy korzystając z warstwy serwisowej.
Kod biznesowy IMO w SQL jest i będzie długi - mało kiedy jest czas na pieszczenie się i szukanie bardziej optymalnej metody na dane zapytanie.
@Długie zapytania:
W językach strukturalnych nawet (nie wspominając o obiektowych) kod można sobie podzielić na procedury tak że jest dużo czytelniejszy. Setki procedur i funkcji na serwerze sql wcale nie są czytelne (trudno je ułożyć w jakąś hierarchię zależności) - duża granulacja to duży bałagan prędzej czy później.
@ORM:
Oczywiście tylko nie wszędzie - jeżeli przetwarzanie dużej ilości danych to raczej na serwerze. Sieć też ma swoją wydajność. CLR na SQL-u z resztą nie daje szansy budowania zapytań w EF.
@Architektura
Bartosz napisał, że trzeba korzystać z tego co umieją developerzy. Nie zgodzę się. Nie można dyktować architektury systemu zdolnościami zespołu - to zespół powinien nagiąć się do architektury. W przeciwnym wypadku dostaniemy łaciaty system z obszarami kreatywności nie do ogarnięcia niczyim umysłem poza umysłem autora :)
Z kolei Marcin pisze, należy WSZYSTKO co się da pisać w bazie danych. Znowu się nie zgadzam to spaczenie odwrotne do używania bazy tylko jako śmietnika na dane. Jasne że wiele da się zrobić w bazie danych jednak myśląc w ten sposób to należało by wszystko pisać w assemblerze bo szybciej i wydajniej kod będzie działał. Oczywiście baza powinna być świątynią danych - powinna zapewnić ich spójność i bronić je przed błędami w aplikacji. Ale żaden większy program (system) nie wytrzyma pakowania go na siłę w bazę danych - szczególnie jeżeli ma być skalowalny i zarządzany.
Wzorcowa aplikacja (architektura) jest opisana tutaj:
http://msdn.microsoft.com/en-us/library/Ee817664(pandp...
Warto trochę poczytać.

Co do prowokacji Stanisława:
przypomina mi się jak podczas awarii systemu w jednym z banków pogadałem sobie z Panią przy okienku która mnie przez to nie mogła obsłużyć. Stwierdziła że kiedyś to było lepiej - było wszystko na kartkach i się dało, a te komputery tylko komplikują i mało wnoszą.
Cóż... tylko wtedy miała może 100 klientów teraz ma 10 000.
Kiedyś wszystko rzeba było załatwiać lokalnie w banku i czekać wieki, teraz można w dowolnej placówce. O dostępie przez Internet nie wspomnę.
Obecne bazy danych to już nie pliki tekstowe - to kombajny - serwery aplikacji. Są dużo bezpieczniejsze, elastyczniejsze, również szybkie, ale bardzo łatwo się podstaw nauczyć dlatego każdy może pisać różne gnioty i narzekać że "nie działa" albo wolno działa.
Nie wspomnę tu o klastrach, xml-ach, usługach sieciowych, BI, dzielenie rekordów na różne pliki / dyski, mechanizmach optymalizacyjnych, backupach, CDC..., audytowaniu. Długo by wymieniać.Tylko z dużą ilością możliwości trzeba się wykazać dużą odpowiedzialnością i głębszą wiedzą o tych "bajerach"/

Blah - to na tyle - HAWK :)
Link do wypowiedziLink
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Temat: CLR Ucieczka od SQL SERVER

No więc (zdania nie należy zaczynać od "no więc":)), jak już wiele razy na tym forum podkreślano, optymalne rozwiązanie zawsze będzie inne w zależności od tego jakie chcemy osiągnąć cele. Nie ma jednego uniwersalnego rozwiązania dla wielu celów.

pozdrawiamROMAN WILK edytował(a) ten post dnia 17.08.11 o godzinie 21:23
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Mimo wszystko dalej się z Panem Panie Sławku podroczę.
Oczywiście postępu nie da się powstrzymać. Tak jak w motoryzacji pojawiły się hamulce tarczowe z F1 i teflon z kosmosu, tak i w informatyce pojawiają się też bardzo potrzebne i inowacyjne rozwiązania. No choćby ... programowanie obiektowe. Jak dobrze obaj wiemy "panienka z okienka" nie jest autorytetem w sprawie baz, zresztą sam też za takiego się nie uważam. Pamientam jednak, jak w latach 80 ubiegłego wieku w dobie ZX Spektrum w programie Sonda panowie Kurek i Kamiński pokazywali system kadrowo-płacowy zainstalowany w Hucie Lenina w Nowej Hucie /10 tys ludzi/ i system nadzoru wielkiego pieca. Wszystko to napisane w Basic'u i zainstalowane na ZX Spektrum 64k RAM i nikomu wtedy o SQL'u się nie śniło. Amerykanie wydali na stworzenie długopisu, który pisze w kosmosie 100 milionów $. Rosjanie latają z ołówkami kopiowymi za 25 kopiejek/sztuka.
Po prostu przerost formy nad treścią. I tak jest właśnie z SQL'em. Nie wiele wnosi, ale jak brzmi.
Jeśli porównamy FOX PRO 2.0 pod DOS'a i obecnego SQL, wyrzucimy wszystkie bajery to zobaczymy, że zostanie nam czysty FOX ten z przed 20 lat. Bo to jest FOX, tylko chłopcy z MS wpieli w niego trochę kwiatków by ładnie wyglądało i przynosiło dochód.
Sam osobiście pamiętam systemy zbudowane na Cliperze, które obsługiwały wszystkie inspektoraty ZUS w całej polsce. Dostęp do danych był od ręki. A jeszcze niedawno w ZUSie było jedno wielkie kino.

A teraz na poważnie.

W zasadzie nie przychodzi mi nic do głowy, czego nie można byłoby zrobić w Cliperze lub w FOXsie, a umożliwiałby to SQL lub robiłby to dużo lepiej. Panowie sprowadźcie minie na ziemię, jakiś przykład/y/. Chętnie wymienię doświadczenia.
Wszystko co Pan wymienił : serwery aplikacji a raczej baz danych, klastry, dzielenie rkordów, fragmentowanie tabel, volumeny, instancje, itd..., to terminy stare jak świat, a ich mechanizmy dawno wykorzystywane i nie ma się czym podniecać. Jedno z czym się zgodzę to że teraz jest lepsze bezpieczeństwo baz i szybkość baz rozproszonych, ale tylko ze względu na technicznie lepszy sprzęt sieciowy i komputerowy. Lepsze protokóły sieciowe i lepsza kompresja przesyłanych danych.
Przepraszam za odbiegnięcie od tematu, ale nabranie dystansu do wszelkich nowości potrzebnych i niepotrzebnych nikomu, pomaga trzeźwiej spojrzeć na problemy które mamy rozwiązać.
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Oczywiście baza PARADOX to jedna z gorszych baz jaką znałem. Nie używałem tez w tamtym czasie dBase, który był nasany w mjakimś bardzo wolnym kompilatorze i wszystko sie ślimaczyło, coć filozofia bazy była niezła. Dopiero Cliper był pierwszą rozsądną bazą i do tego bardzo szybką. Napisany był w C i w dużej części w asamblerze. Filozofia jego była oparta na dBase. Nastepnie pojawił się FOX i to dopiero była jazda na 102. MS jak zwykle przespał sprawę i obudził się po czasie. Kupił FOX'a wraz z wszystkimi licencjami zrobił jego okienkową wersją a mechanizmy wpływające na szybkość bazy i jej bezpieczeństwo przeniósł "swoich" produktów, accessa i nastepnie do SQL'a. 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.
Link do wypowiedziLink

konto usunięte

Temat: CLR Ucieczka od SQL SERVER

Jeszcze jodno zapomniałem. Clipper i FOX to bazy sieciowe z blokowaniem dostepu na poziomie rekordu lub pola. W obu bazach można było nadawać uprawnienia dostępu. Ograniczeniem sieciowym była szybkość sieci, ale takie były czasy i możliwości sprzętu nie mówiąc już o internecie.
Link do wypowiedziLink
Michał Gołuński

Michał Gołuński Programista .NET

Temat: CLR Ucieczka od SQL SERVER

Ja jeszcze tutaj dorzucę moje trzy grosze.

Pierwszy grosik dla mechanizmów replikacji bazy danych i klasteryzacji oprogramowania. Co łatwiej przeprowadzić - stworzyć mechanizm replikacji danych pomiędzy instancjami baz czy też dodać kolejny węzeł serwera który wykonuje ten sam kod? Z mojego doświadczenia wynika że to drugie.

Drugi grosik dla jakości i modyfikowalności kodu. Tak jak już ktoś wspomniał - łatwiej jest zmodyfikować kod kompilowalny który się nie kompiluje w wyniku zmiany schematu niż testować kolejno wszystkie procedury składowane i sprawdzać czy dalej działają i nie powodują błędów. A skoro mowa już o testowaniu - czy ktoś robi testy jednostkowe procedur składowanych? Zwykle są testowane "zewnętrznie" i ich wyniki są sprawdzane, a nie to co się w środku dzieje. Teraz kolejny myk - dotarliśmy do pewnego punktu gdzie jedna z tabel zostaje zastąpiona wywołaniem usługi sieciowej. Klops przy implementacji w T-SQL, betka gdy mamy kod w CLR. No i jeszcze co do jakości - nie wyobrażam sobie długiego kodu w T-SQLu. Powtórzenia kodu, gigantyczne zagłębienie, przetwarzanie na kursorach (sic!) to nie służy jakości.

Ostatni grosik otrzymują ORMy które znacząco upraszczają implementację. Ja mam głównie doświadczenia z LINQ-to-SQL w wersji z mapowaniem tablic przez DataContext, co działa zadziwiająco dobrze nawet dla większych zapytań. Przeglądałem kod SQLa jaki jest generowany na wyjściu tych zapytań i nie miałe żadnych zastrzeżen. Owszem, mega-wielkie-skompilowane zapytanie może nie wyjść, ale szczerze - jeżeli kod twojej metody jest dłuższy niż kilkanaście linijek to robisz coś nie tak.
Link do wypowiedziLink
Roman Wilk

Roman Wilk Tak właściwie, to
gram dużo w squash'a
:), ale to wciąż
z...

Temat: CLR Ucieczka od SQL SERVER

Stanisław Kozłowski:
W zasadzie nie przychodzi mi nic do głowy, czego nie można byłoby zrobić w Cliperze lub w FOXsie, a umożliwiałby to SQL lub robiłby to dużo lepiej. Panowie sprowadźcie minie na ziemię, jakiś przykład/y/.
Obawiam się, że kolega po prostu nie rozumie na czym polega różnica miedzy bazą SQL, a bazą desktop np. CLIPPER. W SQL komunikacja jest wykonywana poprzez zapytania klienta / odpowiedzi serwera (dane sa fizycznie na jednej maszynie, niezależnie czy są READ czy WRITE). To zapewnia po prostu spójność bazy danych i ogranicza ruch po sieci. W przypadku bazy desktop to mechanizmy plikowe decydują o READ /WRITE "bazy", co w przypadku zerwania połączenia sieciowego podczas READ /WRITE skutkuje zazwyczaj katastrofą w spójności bazy.
To jeden powód wyższości SQL nad desktop, przesądzający o konieczności stosowania baz SQL w każdej rozsądnej Aplikacji bazodanowej.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj