Pytanie o prace! SQl i??

Witam znam SQL'a, C, C++, Jave i mam takie pytanie jaki j. programowania jest najczęsciej wymagany od pracodawców którzy wymagają znajomości SQL'a Oracle itd... Słyszałem ze warto nauczyć się VS albo C#. NIe wiem jaka jest prawda. Czy ktoś moze wypowiedzieć sie na ten temat. Chodzi mi głownie o to do czego najbardziej przykładać wagę (oprocz SQL'a) myślać o przyszłosci związanej z bazami danych badź czymś tego rodzaju ;))

dziekuje za odpowiedzi:))

wynika z tego ze doswiadczenie masz zerowe i jezyk "znasz" ale czy umiesz w nim stworzyc aplikacje :P? a co do jezyka jaki wymagaja to przewaznie pisze jak byk w ofercie pracy :P

Doświadczenie jedynie jako Admin, a co do pisania programow to studia+własna inwencja coś tam wyskrobać umiem ale jak to się mówi wiedza jest ale praktyki brak;))
W wiekoszsci ogłoszen rzeczywiscie są podane wymagania, ale chciałem się dowiedzieć co najcześciej wiąze sie z SQL'em ;) chodzi mi oczywiscie o j. programowania ;] czyżby tak jak wspominałem VS?

Marccc napisał(a)

ale chciałem się dowiedzieć co najcześciej wiąze sie z SQL'em ;) chodzi mi oczywiscie o j. programowania ;] czyżby tak jak wspominałem VS?

ja bym stawial na php (przynajmniej jezeli chodzi o ilosc), a co do oracle to podejzewam ze java i c#

Dzieki:)

Poszperam jeszcze po ogłoszeniach i nad czymś usiade dogłębniej:)

Tyle, że pisanie w SQL staje się teraz jak pisanie w asemblerze/C. Jak znasz Jave to poszukaj czegoś o Hibernate.

W przeciwienstwie do kompilatora NHibernate nie zalatwi 95% kwestii optymalizacyjnych.

A nawet powiem, że Hibernate/NHibernate sam z siebie raczej nic nie optymalizuje (no, może poza opóźnianiem update'ów, ale to nie optymalizacja, a raczej 'rule of thumb').
Swoją drogą nie widziałem softu, który optymalizowałby CAŁE procedury pisane dajmy na to w PL/SQL, na raz, tak jak to robią kompilatory. Czyli ktoś sobie głupio napisze 2 pętle zagnieżdżone naiwnie łączące 2 tabele, a kompilator zmieni to na jedno zapytanie z JOINem. To byłaby jazda. ;)

A co do tematu, to jeśli chodzi o duże rozwiązania (Oracle) to głównie Java (J2EE), C# i ASP.NET.
Przy czym Ci co jadą na Oraclu chyba częściej używają J2EE, Ci co maja MSSQL Server raczej .NET.

Theq napisał(a)

Tyle, że pisanie w SQL staje się teraz jak pisanie w asemblerze/C. Jak znasz Jave to poszukaj czegoś o Hibernate.

bzdura :|

Popieram :)
Dalej SQL bedzie uzywany... moze owszem NHibernate czy EF ulatwiaja proste selecty, ale jesli masz do wykonania szereg operacji to wydajniej bedzie zrobic to w Stored Procedurce, ktore tez calkiem ladnie wspolgraja z EF ;)

Kolega pracował w projekcie w którym początkowo był używany Hibernate. Projekt zaczął się rozrastać, potrzebna była wydajność i większa kontrola. W końcu zrezygnowali z Hibernate'a na rzecz JDBC.

Ja pracuje wlasnie nad projektem C#, ktory ze wzgledu na wydajnosc z NHibernate przeszedl prawie calkiem na Stored Procedures Oracle'a. Wlasciwie caly nasz dzial developerow stwierdzil jednoglosnie, ze NHibernate'a trzymamy sie tylko i wylacznie ze wzgledu na przenosnosc, a gdy projekt teho nie wymaga to nie uzywamy do logiki biznesowej.

@Marccc: VS [Visual Studio] to narzedzie edycyjne, zawierajace wsparcie dla C++, C# i kilku innych jezykow; to nie jezyk sam w sobie, choc obslugi samego narzedzia tez koniecznie nauczyc sie trzeba.

Wpisujcie miasta kto jeszcze porzucił ORMy.

AdamPL napisał(a)

Theq napisał(a)

Tyle, że pisanie w SQL staje się teraz jak pisanie w asemblerze/C.

bzdura :|

Prawdziwi mężczyźni programują tylko w fortranie? Tak, ORMy są wolniejsze, w szczególnych przypadkach nawet o rząd wielkości. Jak wydajność jest niezadowalająca to nikt nie broni przed optymalizacją w SQLu. Co nie zmienia faktu, że dzięki nim pisze się szybciej, łatwiej i jest mniejsze ryzyko błędu. Coś jak asm/C vs Java? Czy może się mylę, ORMy nigdy nie powinny powstać, bo przecież prawdziwi mężczyźni...

asm/C vs Java jest złą analogią, bo Java zawiera w sobie pełnoprawny, optymalizujący kompilator do kodu maszynowego (a nawet dwa). Natomiast ORM to tylko nakładka, generująca gdzieś dalej SQLa optymalizowanego dopiero przez RDBMS. Problem w tym, że obecne ORMy w ogóle nic nie optymalizują, są raczej głupimi tłumaczami z jednego modelu na drugi, wg ściśle określonych reguł. Dobra wiadomość jest jednak taka, że jak się wie, co dany ORM generuje i jakie ma opcje, to najczęściej daje się uzyskać zbliżoną wydajność, znacznie mniejszym nakładem i przy znacznie czytelniejszym projekcie. Hibernate'a można kontrolować w bardzo dużym stopniu, a w sytuacjach skrajnych wręcz przejść na czystego SQLa nadal nie rezygnując z modelu obiektowego po stronie aplikacji.

Optymalizowałem wiele aplikacji po różnych programistach i najczęściej ci, którzy najbardziej kręcili nosem na Hibernate'a ("moja aplikacja się muli - to na pewno przez Hibernate'a"), przechodząc na czystego SQLa nie osiągnęliby lepszej wydajności. Bo problem był jak zwykle między krzesłem a monitorem. ;)

Nie no, jasne... tylko problem zaczyna sie wtedy, gdy zalozenie, ze baza danych i aplikacja webowa znajduja sie na jednej maszynie lub w szybkiej sieci, okazuje sie nieprawdziwe. W aplikacjach korporacyjnych tworzonych przez moja obecna firme czesto tak nie jest i ograniczac nalezy nie tylko czas operacji, ale rowniez ilosc przesylanych danych. Za tym idzie automatycznie prowadzenie obliczen biznesowych wylacznie po stronie bazy i tylko oddawanie wynikow Hibernate'owi. Nie napisalem, ze zrezygnowalismy z Hibernate'a, ale wolimy obciazyc baze danych niz aplikacje webowa, a z tego Hibernate nikogo nie wyreczy.

@Theq: Nie napisalem jednak tego, by zaprezentowac jak bardzo nie lubie ORM, bo tak nie jest. Chodzi o to, ze Marccc pytal o prace ze znajomoscia SQL Oracle'a i napisalem to, by pokazac, ze to, co wspomniales o "niskopoziomowosci" w stosunku do Hibernate to komplenta bzdura, bo kod napisany bez Hibernate jest na ogol krotszy i czytelniejszy, o ile programista umie go stworzyc. Hibernate zmienia widok na model danych, uniezaleznia od uzytej bazy, ale nie robi czegos lepiej niz programista i przez to nie zwalnia go z wiedzy o dzialaniu RDBMS.

Dlatego znajomosc Oracle (czy SQL Server, etc) bedzie przydatna nawet mimo Hibernate, bo ten nie dziala zamiast adaptera bazy danych ale na nim (w przeciwnosci do asma).

Dzieki wszystkim za wypowiedzi:) Naprawdę ciekawe rzeczy się dowiedziałem:]
THX ALL!

Przepraszam ale czemu w ogóle wchodzicie w dyskusje z kimś kto porównuje framework ORM z bazą danych i językiem zapytań? Porównujemy przecież dwie różne rzeczy. Absolutnie wszystkie funkcjonalności biznesowe zaimplementowane i uruchomione na bazie danych wykonują się o wiele szybciej, chyba, że mówimy o bazkach, a nie o bazach danych. Każda porządna baza ma już zaimplementowane mechanizmy buforowania danych. Hibernate służy do zupełnie czegoś innego i nie chodzi o to, że tego nie lubię lub nie używam :|

Szczawik napisał(a)

ale wolimy obciazyc baze danych niz aplikacje webowa, a z tego Hibernate nikogo nie wyreczy.
Też bym wolał jak bym musiał.

Szczawik napisał(a)

napisalem to, by pokazac, ze to, co wspomniales o "niskopoziomowosci" w stosunku do Hibernate to komplenta bzdura.
Co najwyżej skrót myślowy ;)

Szczawik napisał(a)

bo kod napisany bez Hibernate jest na ogol krotszy i czytelniejszy, o ile programista umie go stworzyc.
Masz chyba na myśli kod, który wygeneruje Hibernate od kodu napisanego bez niego :P Bo w ORMie się jednak pisze zdecydowanie szybciej i mniej, przynajmniej mnie.

Szczawik napisał(a)

Dlatego znajomosc Oracle (czy SQL Server, etc) bedzie przydatna nawet mimo Hibernate, bo ten nie dziala zamiast adaptera bazy danych ale na nim (w przeciwnosci do asma).
Zgadzam się i nigdy nie twierdziłem inaczej, może wyraziłem się nieprecyzyjnie. Starałem się odpowiedzieć na pytanie autora
Chodzi mi głownie o to do czego najbardziej przykładać wagę (oprocz SQL'a) myślać o przyszłosci związanej z bazami danych badź czymś tego rodzaju.

AdamPL napisał(a)

Absolutnie wszystkie funkcjonalności biznesowe zaimplementowane i uruchomione na bazie danych wykonują się o wiele szybciej, chyba, że mówimy o bazkach, a nie o bazach danych.
Mówie o bazkach. Czy to znaczy, że nie ma tu dla mnie miejsca bo moje bazki nie przetwarzają setek tysięcy zapytań na sekundę, a tobie daje to prawo do imputowania mi, że nie znam różnicy między ORMem a bazą danych?

AdamPL napisał(a)

Przepraszam ale czemu w ogóle wchodzicie w dyskusje z kimś kto porównuje framework ORM z bazą danych i językiem zapytań? Porównujemy przecież dwie różne rzeczy.
Szczególnie, że język zapytań wchodzi w skład ORMa ;)

Theq napisał(a)

AdamPL napisał(a)

Absolutnie wszystkie funkcjonalności biznesowe zaimplementowane i uruchomione na bazie danych wykonują się o wiele szybciej, chyba, że mówimy o bazkach, a nie o bazach danych.
Mówie o bazkach. Czy to znaczy, że nie ma tu dla mnie miejsca bo moje bazki nie przetwarzają setek tysięcy zapytań na sekundę, a tobie daje to prawo do imputowania mi, że nie znam różnicy między ORMem a bazą danych?

Na bazkach wszystko chodzi na tyle szybko, że nie ma potrzeby żadnej optymalizacji. Jednak pracując w taki sposób nabywa się złych nawyków i gdy nagle trzeba obsłużyć dużą bazę to okazuje się, że dotychczasowe metody nie zdają rezultatu, bo wszystko nagle działa zbyt wolno.

Theq napisał(a)

AdamPL napisał(a)

Przepraszam ale czemu w ogóle wchodzicie w dyskusje z kimś kto porównuje framework ORM z bazą danych i językiem zapytań? Porównujemy przecież dwie różne rzeczy.
Szczególnie, że język zapytań wchodzi w skład ORMa ;)

Nie wiesz co to jest spójnik czy zabrakło argumentów?

Na bazkach wszystko chodzi na tyle szybko, że nie ma potrzeby żadnej optymalizacji.

Też tak myślałem, dopóki nie zobaczyłem "bazki" zawierającej raptem 5 tys. użytkowników (tak! pięć tysięcy), która obsługiwała stronę z pięcioma podstronami i... strona główna serwisu ładowała się 50-90 sekund przy obciążeniu jednym użytkownikiem. Goście, którzy to projektowali chyba też myśleli, że skoro jest mało użytkowników, to system sobie sam poradzi. A tu zonk. Fakt, na Oraclu ta stronka śmigałaby pewnie kilka-kilkanaście razy szybciej (to było na Postgresie), ale wystarczyło nieco ruszyć głową, by przez zmianę zapytań zmniejszyć czasy do 2-3 sekund (i tak za dużo, ale dalej to już cały projekt by trzeba było zmieniać).

@Krolik - ok zagalopowałem się w tym stwierdzeniu. Błędnie założyłem, że poprawianie ewidentnych błędów popełnionych w czasie projektowania i programowania nie można nazwać optymalizacją. We wszystkich pozostałych dziedzinach nauki "optymalizacją" nazwiemy tylko poszukiwanie najlepszego rozwiązania. W przypadku programowania "optymalizacją" jest każda poprawka w kodzie zmniejszająca czas jego działania i ilość zużywanych zasobów :)