GoldenLine
Zaloguj się
Łukasz Sokół

Łukasz Sokół Webdesigner

Temat: Znajomość ASP.NET, C# i MS SQL

Witam,
Od niedawna interesuję się platformą .NET a właściwie wyżej wymienionych w temacie.
Tutaj nasuwa mi się pytanie czy szukając pracy konieczna jest znajomość wszystkich trzech rzeczy czy np. są stanowiska gdzie używa się tylko ASP.NET a inny programista koduje to w C# itp?

Może to głupie pytanie ale tak jakoś mi się nasunęło :)
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Raczej nie ma. W samym markup'ie to niewiele zrobisz - dlatego znajomość C# (albo VB.NET) jest raczej potrzebna.

Już prędzej z Silverlightem tu niektóre firmy (na razie głównie zachodnie) idą w specjalistów od XAML'a i programistów, który robią bebechy (choć oczywiście nic nie stoi na przeszkodzie abyś robił z powodzeniem obie rzeczy).
Link do wypowiedziLink
Łukasz Sokół

Łukasz Sokół Webdesigner

Temat: Znajomość ASP.NET, C# i MS SQL

czyli trzeba się przyłożyć też do c# :) no cóż mus to mus :)
Link do wypowiedziLink
Michał K.

Michał K. .NET Developer

Temat: Znajomość ASP.NET, C# i MS SQL

Tak jak kolega Paweł powiedział, albo VB.NET, ale raczej C#. Większość firm, przynajmniej ja się z takimi spotkałem, preferuje C#.
Link do wypowiedziLink
Sebastian Marek Gruchacz

Sebastian Marek Gruchacz Senior .Net
Developer at Grupa
Pracuj

Temat: Znajomość ASP.NET, C# i MS SQL

PRAWDOPODOBNIE możesz sobie odpuścić na początek SQL... ale raczej nie polecam - szansa na to, ze w firmie będziesz mieć DB designerów / architektów co wszystko zakodują jest mizerna...

Poza tym - jeśli masz się uczyć dostępu przez ADO i podobnych (w sumie główne użycie ASP.Net) - to jakiś przynajmniej testowy SQL czy bazę powinieneś umieć stworzyć.

Raczej traktowałbym to jako nierozerwalne kombo. I jak koledzy pisali - raczej C# niż VB.
Link do wypowiedziLink
Łukasz Sokół

Łukasz Sokół Webdesigner

Temat: Znajomość ASP.NET, C# i MS SQL

Pytam gdyż właśnie od niedawna uczę się ASP.NET oraz w minimalnym stopniu C# i jak na razie bardzo mnie zainteresowało. Wracając do SQL a co jeśli cały serwis www ma się opierać na bazie bo tak jest w 90% :) wtedy SQL zazwyczaj zajmuje się kto inny czy osoba odpowiedzialna za C# i ASP.NET?
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Ja uważam, że przynajmniej podstawowa wiedza z zakresu SQL się przyda. Co prawda coraz więcej jest ORM'ów i różnego rodzaju frameworków, które za nas biorą cały trud SQL'a - ale czasem dobrze wiedzieć co nam tam generują. Nie koniecznie musisz być masterem SQL'a i świetnym optymalizatorem zapytań - ale jak napisać SELECTa, INSERTa, UPDATEa i DELETEa powinieneś znać.
Link do wypowiedziLink
Michał K.

Michał K. .NET Developer

Temat: Znajomość ASP.NET, C# i MS SQL

Sebastian Marek Gruchacz:
...szansa na to, ze w firmie będziesz mieć DB designerów / architektów co wszystko zakodują jest mizerna...
U mnie tak jest. Szczerze powiem średnio mi to odpowiada, no ale cóż, nie ja ustalam zasady gry. ;-)

I znowu przyznam rację Pawłowi, podstawowa wiedza z SQLa przyda się.
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Sebastian Marek Gruchacz:
PRAWDOPODOBNIE możesz sobie odpuścić na początek SQL... ale raczej nie polecam - szansa na to, ze w firmie będziesz mieć DB designerów / architektów co wszystko zakodują jest mizerna...

Nie ma znaczenia czy w firmie są "DB Designerzy" i "DB Architekci", ponieważ ich rola zupełnie nie jest związana z SQL. Programowanie SQL wciąż należy do developerów.Maciej Z. edytował(a) ten post dnia 15.12.08 o godzinie 02:49
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Paweł Łukasik:
Co prawda coraz więcej jest ORM'ów i różnego rodzaju frameworków, które za nas biorą cały trud SQL'a - ale czasem

Z mojego doświadczenia generowanie dynamicznych zapytań SQL za pomocą wszelkich frameworków - TYLKO i wyłącznie przy małych projektach. Poważniejsze rozwiązania i dynamiczny SQL to strata czasu.
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Maciej Z.:

Z mojego doświadczenia generowanie dynamicznych zapytań SQL za
pomocą wszelkich frameworków - TYLKO i wyłącznie przy małych projektach. Poważniejsze rozwiązania i dynamiczny SQL to strata > czasu.

Nie wiem co rozumiesz pod pojęciem poważniejszych rozwiązań, ale nie zgodzę się z tym z piszesz. Ja bym raczej powiedział, że już prędzej w małych projektach to strata czasu. W dużych stratą jest pisanie SQL od razu na początku projektu. Lepszym rozwiązaniem jest skorzystanie z ORM'a i dopiero w późniejszym okresie jeśli widzimy, że mamy problem z wydajnością w zapytaniach SQL przyśpieszanie go. Jeszcze raz podkreślę jednak, że nie neguję potrzeby znajomości SQL'a.
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Maciej Z.:
Z mojego doświadczenia generowanie dynamicznych zapytań SQL za pomocą wszelkich frameworków - TYLKO i wyłącznie przy małych projektach. Poważniejsze rozwiązania i dynamiczny SQL to strata czasu.

Pisanie bezpośrednio zapytań ma wiele wad z których najważniejsza to duża trudność refactoringu, a zadania takie jak zmiana bazy danych często są już niewykonalne. Im projekt większy tym skala problemu rośnie (bynajmniej nie liniowo). Wtedy warto stosować ORMy i automaty generujące SQL, to rozwiązuje 95% problemów, a resztą zajmie się już SQL pisany ręcznie.

Popatrz na forum JAVA, tam ten temat był wałkowany kilka lat temu.
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Nie będę polemizował, nie płacą mi tutaj za popisywanie się głębszą wiedzą. Powiem tylko "enigmatycznie" (dla niektórych): stored procedures.Maciej Z. edytował(a) ten post dnia 16.12.08 o godzinie 01:40
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Nie wiem co rozumiesz pod pojęciem poważniejszych rozwiązań, ale nie zgodzę się z tym z piszesz. Ja bym raczej powiedział, że już prędzej w małych projektach to strata czasu. W dużych stratą jest pisanie SQL od razu na początku projektu.

Ciekawe :-) Sorry, rozmijamy się w pierwszej linii. Myślę i myślę czemu tak piszesz, ale nie będę spędzał nad tym sporo czasu. Pewnie można załagodzić i po prostu sprowadzić do tego że dla Ciebie duże, to dla mnie małe i dalej już można się tylko spierać :-)Maciej Z. edytował(a) ten post dnia 16.12.08 o godzinie 01:52
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Sebastian Pienio:
Maciej Z.:
Z mojego doświadczenia generowanie dynamicznych zapytań SQL za pomocą wszelkich frameworków - TYLKO i wyłącznie przy małych projektach. Poważniejsze rozwiązania i dynamiczny SQL to strata czasu.

Pisanie bezpośrednio zapytań ma wiele wad z których najważniejsza to duża trudność refactoringu, a zadania takie jak zmiana bazy danych często są już niewykonalne. Im projekt większy tym skala problemu rośnie (bynajmniej nie liniowo). Wtedy warto stosować ORMy i automaty generujące SQL, to rozwiązuje 95% problemów, a resztą zajmie się już SQL pisany ręcznie.

Popatrz na forum JAVA, tam ten temat był wałkowany kilka lat temu.

Zgoda, ale zakładając że nie doczytałeś mojej wypowiedzi. Wszystko fajnie, ale tylko przy małych projektach, gdzie kupujesz farmę serwerów za kilkaset tysięcy USD i masz sporo mocy na przetwarzanie dynamicznie generowanych zapytań. Przy większych rzędy wielkości kosztów i mocy przetwarzania rosną gigantycznie, a miejsca na niezoptymalizowane zapytania nie ma w ogóle. Tutaj zaczyna się tuning konfiguracji serwerów i samych zapytań.Maciej Z. edytował(a) ten post dnia 16.12.08 o godzinie 02:05
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Paweł Łukasik:
Maciej Z.:

Z mojego doświadczenia generowanie dynamicznych zapytań SQL za
pomocą wszelkich frameworków - TYLKO i wyłącznie przy małych projektach. Poważniejsze rozwiązania i dynamiczny SQL to strata > czasu.

Nie wiem co rozumiesz pod pojęciem poważniejszych rozwiązań, ale nie zgodzę się z tym z piszesz. Ja bym raczej powiedział, że już prędzej w małych projektach to strata czasu. W dużych stratą jest pisanie SQL od razu na początku projektu. Lepszym rozwiązaniem jest skorzystanie z ORM'a i dopiero w późniejszym okresie jeśli widzimy, że mamy problem z wydajnością w zapytaniach SQL przyśpieszanie go. Jeszcze raz podkreślę jednak, że nie neguję potrzeby znajomości SQL'a.

Właściwie zgadzasz się ze mną. Sorry, twoja wypowiedź że "nie zagadzam się" "trochę" mnie zmyliła :-) Tak, mam na myśli rozwiązania w których nie liczy się jak szybko przepchniesz projekcik przez drzwi, ale tam gdzie liczą się ułamki sekund w czasie wykonania zapytań. To właśnie mam na myśli przez poważniejsze, większe projekty i tutaj wydaje się że jednak się zgadzamy.
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Sebastian Pienio:
Popatrz na forum JAVA, tam ten temat był wałkowany kilka lat temu.

Z pewnością, ale nie będę sprawdzał tego wątku i zaufam jednak swojemu doświadczeniu, kwalifikacjom i empirycznej wiedzy ;-) Dynamiczny SQL ma wiele zalet, ale jednak statycznie skompilowane zapytania "stuningowane" przez specjalistę o odpowiednich kwalifikacjach będą ZAWSZE per saldo szybsze i przy większych projektach wydajność zapytań właśnie będzie jedynym kryterium oceny.Maciej Z. edytował(a) ten post dnia 16.12.08 o godzinie 02:15
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Maciej Z.:
Właściwie zgadzasz się ze mną. Sorry, twoja wypowiedź że "nie zagadzam się" "trochę" mnie zmyliła :-) Tak, mam na myśli rozwiązania w których nie liczy się jak szybko przepchniesz projekcik przez drzwi, ale tam gdzie liczą się ułamki sekund w czasie wykonania zapytań. To właśnie mam na myśli przez poważniejsze, większe projekty i tutaj wydaje się że jednak się zgadzamy.

Nie miałem na myśli szybkiego przepchnięcia projektu. Raczej chodziło mi, że nie ma co szukać i od razu optymalizować bottle-necka na poziomie aplikacja-baza, bo może się okazać, że optymalizacja w innym miejscu da danm dużo więcej.

Jeśli mówimy o systemach, w których liczą się ułamki sekund (ale mam tu na myśli głównie jakieś systemy czasu rzeczywistego) to zgadzam się, bezpośrednie zapytania będą szybsze, gdyż będzie można je pod każdym względem wydajnościowym zoptymalizować pod nasz problem.

W moim poście odnośnie ORM'ów chodziło raczej o rozwiązania desktopowe, w których to użycie ORM'a ma sens, bo musisz np. wspierać dwa/trzy/więcej* różne systemu RDBMS.

* - niepotrzebne skreslić
Maciej Z.:
Dynamiczny SQL ma wiele zalet, ale jednak statycznie
skompilowane zapytania "stuningowane" przez specjalistę o
odpowiednich kwalifikacjach będą ZAWSZE per saldo szybsze i przy
większych projektach wydajność zapytań właśnie będzie jedynym
kryterium oceny.

Zgadzam się, tylko tuning zapytań nie wyklucza użycia ORM'a. Brałem udział w projekcie, w którym specjalista tuningował zapytania generowane przez ORM'a (zmieniana był kod ORM'a) na potrzeby bazy Oracla. Ja nigdy nie powiedziałem, że zapytania wygenerowane przez ORM'a będą szybsze. Wiadomo, jak coś jest do generalnego użycia to nie będzie tak szybkie jak coś napisane specyficznie pod dany problem. Chodzi mi o to, że można zacząć od ORM'a a w razie potrzeby optymalizować.Paweł Łukasik edytował(a) ten post dnia 16.12.08 o godzinie 08:04
Link do wypowiedziLink

konto usunięte

Temat: Znajomość ASP.NET, C# i MS SQL

Maciej Z.:
Z pewnością, ale nie będę sprawdzał tego wątku i zaufam jednak swojemu doświadczeniu, kwalifikacjom i empirycznej wiedzy ;-) Dynamiczny SQL ma wiele zalet, ale jednak statycznie skompilowane zapytania "stuningowane" przez specjalistę o odpowiednich kwalifikacjach będą ZAWSZE per saldo szybsze i przy większych projektach wydajność zapytań właśnie będzie jedynym kryterium oceny.

Wydajnosc zapytan jest zalezna od struktury bazy, a ta zalezy od struktury aplikacji i jej strategii uzyskania danych. Piszac statyczne SQL zyskujesz krok do przodu ale zamykasz sie na refactoring, ktory czesto umozliwia 5 krokow do przodu, obrazowo uzasadnic mozna tak:

To mniej wiecej tak jak wycieczka przez Europe. Pierwszych kilka ulic szybciej pokonasz pieszo, ale pozniej rower okaze sie szybszy, a na dluzsza mete oplaca sie odpalic samochod (bo na wiecej niespodzianek sie przygotujesz, a nie wiesz co Cie w drodze spotka). Tak i w programowaniu, na krotka mete mozesz pisac calego SCRUDa w procedurach skladowanych. Ale gdy projekt ma lifetime wiekszy niz 2-3 lata to wtedy jego utrzymanie (maintenance) staje sie glownym kosztem. Wtedy mozliwosc zmiany lokalizacji danych, sposobu ich trzymania czy nawet strategii uzyskania jest znacznie wazniejsza niz najlepiej na swiecie zoptymalizowane przez "kwalifikowanego" specjaliste zapytanie, bo jest ono ograniczone aktualna struktura bazy.

Widzialem wiele projektow tworzonych wg ideologii Microsoftu (na stored procedures) i zaden z nich nie dzialal szybko i sprawnie. Nie przekonywalo to developerow twierdzacych, ze gdyby nie stored procedures to byloby to jeszcze wolniejsze ;)

Nowa wiedze zawsze biore pod uwage niezaleznie od moich "kwalifikacji" ;)
Link do wypowiedziLink
Maciej Z.

Maciej Z. taskbeat.pl

Temat: Znajomość ASP.NET, C# i MS SQL

Sebastian Pienio:
Widzialem wiele projektow tworzonych wg ideologii Microsoftu (na stored procedures) i zaden z nich nie dzialal szybko i sprawnie. Nie przekonywalo to developerow twierdzacych, ze gdyby nie stored procedures to byloby to jeszcze wolniejsze ;)

Nowa wiedze zawsze biore pod uwage niezaleznie od moich "kwalifikacji" ;)

Obawiam się że to nie ideologia, ale doświadczenia, testy, testy i jeszcze raz testy. Ponownie, pewne rzeczy wychodzą tylko w większych rozwiązaniach. Jeżeli nie możesz potwierdzić tego na swoim ogródku, to znaczy że jest to inny ogródek niż ten z "ideologii" Microsoftu. T-SQL i stored procedures to nie jest zresztą żadna ideologia żadnej firmy, ale lekcja nr jeden na najbardziej podstawowych kursach Microsoft SQL Server, Sybase Adaptive Server Enterprise, czyli całemu środowisku T-SQL.

Szanuję jednak Twoją odmienną opinię, ale stawiasz ją przed murem specjalistów w zakresie dużych baz danych, nie tylko - jak zauważyłeś - z firmy Microsoft.Maciej Z. edytował(a) ten post dnia 16.12.08 o godzinie 22:24
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Początki ASP.NET




Wyślij zaproszenie do
Anuluj