Witam.
Siedzę długo w SQL. Dosyć zaawansowany poziom. 5 lat z Oracle. Wszystkie zapytania pisane z palca bez ORM.
Pytanie: czy w nowych (słowo klucz) projektach jest jeszcze potrzebna znajomość SQL na bardziej niż podstawowym poziomie?
Oczywiście wiadomo, że lepiej znać niż nie znać. Wiadomo też ze ORM wypiera SQL gdzie tylko może/gdy tylko może.
Wiadomo też że w n % przypadków (n raczej bliżej 100 niż 0) lepiej użyć ORM. Natomiast czy lim(n) = 100%?
Wypowiedzcie się prosze.
Dodam, że moje pytanie nie brzmi czy jestem dinozaurem:D
Używam jednego i drugiego. Poza tym ORM nie wyklucza używania SQL jako języka zapytań. Im bardziej skomplikowane query tym bardziej preferuje SQL.
co jakis czas mi sie sql przewija w pracy, orm tylko sporadycznie
jeszcze potrzebna znajomość SQL na bardziej niż podstawowym poziomie?
Co to znaczy na wyżej niż podstawowym poziomie?
Bo sam SQL dla devów to nie jest jakieś nie wiadomo co
A ORM nie zawsze wystarczają
I tak trzeba zweryfikować, czy ORM robi to co trzeba tak jak trzeba. Czyli trzeba wygenerować plan zapytania i sprawdzić, czy nie dzieje się tam jakaś tragedia. Można do tego średnio rozumieć sql, ale jeśli przyjdzie potrzeba optymalizacji takiego zapytania, to szybko okaże się, że jednak trzeba się co najmniej dobrze na tym znać, albo trzeba co najmniej dobrze znać osobę, która się na tym co najmniej dobrze zna ;-)
dziwne pytanie. no pewnie, że SQLa warto znac i nwm jak można dobrze ogarniać ORMa bez SQLa? sql to klasyka, sql jest nice
co to znaczy "rozwijać SQL" ? SQL na średnim poziomie można sobie ogarnąć w parę dni, przecież w standardzie to może z 20-30 funkcji.
co do dialektów - to prawie nigdy nie opłaca się ich "samych w sobie uczyć", do momentu jak jakiś projekt tego nie wymaga.
mamy **standard SQL **- to trzeba mieć w małym palcu, praktycznie na każdej rozmowie kwalifikacyjnej musiałem wyśpiewać SELECTy (zawsze to uważałem za najprostsze i pewniak)
no i mamy dialekty SQL - to według mnie zależnie od projektu, ale wraz z doświadczeniem zawodowym warto ogarnąć parę dialektów (MySQL, PL/SQL)
właśnie co do dialektów - w mojej działce dominują: PostgreSQL, MySQL, no i PL/SQL (sqldeveloper) czyli Oracle
trochę zależy czy pracuje się akurat z PHPowcami czy javovcami, czy nawet RoRowcami.
jest jeszcze kwestia skryptów automatyzujących, generalnie SQL wiąże się dosyć fajnie ze skryptowaniem - jak już ktoś myśli jak się rozwijać, to zawsze można sobie zacząć w kółko wałkować skrypty ;)
Tu raczej chodzi o wygodę dla programisty i szybkość tworzenia oprogramowania. Weźmy np. jakiś framework PHP oraz Active Record Pattern. No jest też Data Mapper ale z czegoś takiego to swego czasu korzystałem w jednej aplikacji pod Androida którą pisałem. W PHP jest o tyle dobrze że nie trzeba nawet definiować nazw zmiennych w klasach, jak również getterów i setterów, to się może odbywać przeźroczyście (np. stdClass). Łatwo można również konwertować array na stdClass i na odwrót.
Właśnie kończę pewien serwis na frameworku, moduł ORM wykorzystuje właśnie Active Record. To raczej nie jest złożony projekt, natomiast moduł ORM znakomicie ułatwia zadanie (w CRUD), co nie znaczy że wszędzie, bo w niektórych miejscach to jest SQL i joiny po wielu tabelach (ale z wykorzystaniem Query Buildera). Oczywiście mam też wgląd w to jakie zapytania SQL się wykonują i ile czasu zajmują.
poza tym jak zweryfikujesz działanie ORM bez znajomości SQL?