Co to znaczy dobra znajomość SQL / Baz danych?

Gdy widzicie że ktoś ma w CV wpisane

"dobra znajomość SQL / Baz danych"

czy jak tam wolicie w gwiazdkach: z , gdzie (1=amator, 5=expert)

to jakie macie oczekiwania od takiej osoby? oczywiście w kontekście programisty, a nie dba.

PS:

tak mnie naszło, a może zbyt duża biegłość w bazach to wada przy programowaniu, bo później więcej próbuje się zrobić po stronie bazy? no wiecie widoki, procedurki, triggerki. temp tables itd. bo "po stronie bazy szybciej" ;)

1. Potrafi napisać zapytania, w których używa joinów, group by, having, sub selectów, itp.
2. Wie co to jest widok i potrafi go stworzyć - to jest zwykłe zapytanie, więc jak umie punkt 1), to z tym też se powinien poradzić, nawet jeśli wcześniej nie tworzył widoków.
3. Wie jak optymalizować zapytania - np. użycie indexów.
4. Stosuje postaci normalne, nie wymagałbym tu żeby pamiętał regułkę czym dokładnie jest postać I, II i III, po prostu gość powinien wiedzieć o co w nich chodzi.
5. Triggerów i procedur bym nie wymagał, to nie jest jakoś często stosowane.
6. Wie co to SQL injection i jak się bronić przed tym - np. parametryzacja zapytań po stronie kodu.
7. Zna jakiś framework do pracy z bazami, np. Doctrine w PHP.
8. Umie rozróżnić bazy relacyjne od nierelacyjnych, wie do czego służą. Potrafi podać jakieś przykłady.
9. Potrafi podać zalety/wady robienia niektórych rzeczy w kodzie zamiast bezpośrednio w bazie (chociaż to akurat może być już ponad standardową znajomość).

@serek: prawie wszystko, co wymieniłeś zaliczył bym raczej pod podstawową znajomość SQL, a nie dobrą ;) to że ktoś nie zafunduje SQLi na dzień dobry, bo wie że sklejanie zapytań na partyzanta to proszenie się o kłopoty nie czyni jeszcze mocnym zawodnikiem :D

Dobra znajomość dla mnie oznaczałaby coś szerszego, na przykład

• Wiedza na temat tego, jak działają poszczególne typy indeksów, jak są budowane i z czym to się wiąże - z tą wiedzą agent będzie się orientował, który w danej sytuacji się nada zamiast zawsze zakładać domyślny
• Jakieś pojęcie o tym, w jaki sposób DBMS / silnik który delikwent dobrze zna składuje dane, jakie ma ograniczenia itd
• Orientowanie się w takich tematach jak migrowanie danych, kompatybilność wstecz / wprzód, powinien też wiedzieć jak działa i jakie ma konsekwencje partycjonowanie oraz replikacja bazy danych - nie po to, żeby z marszu wrzucał to do każdej bazy, ale żeby nie robił tego na pałę tylko uważał bo można zrobić sobie kuku

Jeśli dobra, to powinien jeszcze znać poziomy izolacji transakcji, zasady ich działania.

W praktyce to oznacza znajomość jakiegoś ORM-a :D

superdurszlak napisał(a):

@serek: prawie wszystko, co wymieniłeś zaliczył bym raczej pod podstawową znajomość SQL, a nie dobrą ;)

Czy ja wiem. Gdyby chodziło o dobrą znajomość baz gościa, który się głównie nimi zajmuje, to się zgodzę. Ale w temacie chodzi o dobrą znajomość w odniesieniu do programisty. Więc ja bym tu trochę lżej do tematu podchodził.

Dodatkowo bym dodał jeszcze np. używanie transakcji.

To zależy też czy z punktu widzenia programisty czy z punktu widzenia bazodanowca.

3/5 czy 5/5?

Poza tym sam SQL to raczej dość płytki temat, więc trzeba mówić o konkretnej technologii, zakładam że Oracle bo to raczej standard przy rekrutacjach.

3/5 to:

• na pytanie co zrobi żeby poprawić zapytanie które z jakiegoś powodu długo się wykonuje bezwzględnie odpowiada "sprawdzę plan zapytania" a nie że użyje indeksów (żeby pisać zapytanie bez koniecznych indeksów trzeba być idiotą, pytanie co zrobić jak indeksy już tam są)
• najlepiej żeby znał PL/SQL przynajmniej zgrubnie i umiał napisać prosty skrypt
• wie co to jest trigger
• potrafi opisać poziomy izolacji i efekty typu phantom reads
• wie jak sprawdzić co lockuje daną tabelę
• potrafi poprawnie dobrać typ danych do kolumny
• używa WITH ;p

4/5 - 5/5 to:

• zna bardzo dobrze PL/SQL, potrafi w nim napisać dowolne przetwarzanie danych i integracje z technologiami typu Java
• potrafi optymalizować zapytania hintami
• potrafi skutecznie partycjonować tabele
• potrafi korzystać z klienta konsolowego i przenieśc danem db dumpem
• potrafi zaproponować optymalizację bazy na poziomie administracyjnym

Uwaga to nie są skille na administratora czy developera stricte Oraclowego, tylko na developera Javy który używa Oracla.

Sama znajomość zapytań SQL to jest dla mnie 1/5, to powinien znać każdy QA a nie developer.

Większość firm jednak nie ma DBA, więc taka odpowiedzialność spada na programistów, no i jak ktoś jest stricte backend developerem i ma pracować z SQLem i odpowiadać za jego zarządzanie, no to strach osoby bez takiej wiedzy zatrudniać.

@urke u mnie w ex firmie byl ziom od sql :D a i tak appka zdychala bo baza do kosza. Podobno jak odchodzielm jakeigos DBA zatrudniali ale kto wie czy cos poprawil. Ogolnie ja jak developer nienawidze baz danych traktuje je jako zlo konieczne. I jako fullstack niestety i po sql musialem grzebac. Dobrze jest jak mialem podobne zapytanie pisane to na luzie dawlaem rade napisac swoje wzorujac sie :P. Nigdy sie w tym mocny nie czulem i nie przedam za SQL. Jak firma zydzi na DBA to jej sprawa a pozniej jej to sie czkawka odbije jak aplikacja przestanie odpowiadac i tylko zwiekszenie timeoutow pomoze.

@The Pontiff: Poza tym sam SQL to raczej dość płytki temat

No błagam Cię człowieku!

W podanej przez Ciebie skali oceniania jestem 5/5 a wiem, że nawet do pięt nie dorastam specjalistom z tej branży i nie śmiałbym ocenić się na wyżej niż 2,5 max 3 i nie mówię o porównywaniu się z administratorami czy projektantami a zwykłymi programistami z którymi miałem okazje wielokrotnie współpracować.

Programista jak nie ma podstaw o działaniu bazy to napisze tak kretyńskie zapytania, że nawet najlepsza struktura bazy i złoty administrator nie uratują serwerów przez ubiciem.

SQL to jest standard języka, a nie to co powyżej czyli ogólnie bazy danych. Sama znajomośc SQL-a wg mnie niewiele daje, chyba że ktoś chce się chwalić że wie jak utworzyć tabelę.

Co do skali no to oczywiście jest względna, znam kilku developerów którzy według mojej skali są 5/5 i od nich się uczyłem wielu bardziej zaawansowanych rzeczy, nie przeczę że mogą być tacy którzy wg niej mieliby 10/5 bo Oracle to jest gigantyczny temat i człowiek cały czas ma wrażenie że nic nie wie. Natomiast na rekrutacji nigdy nie miałem kandydata nawet 3/5. Ludzie nie rozumieją podstawowych rzeczy i to tacy z 10 letnim doświadczeniem jako snior java dev który czego to nie robił w CV.

@The Pontiff: dobrze gada sama znajomosc sql to jak znajomosc C#, trzeba znać możliwości, środowisko, jak rozwiązań dany problem a nie jak napisać seleta z group by. Nie wspominajc ze sam SQL to pol biedy bo kazda baza ma swoje psikusy :D

@WeiXiao mam jakieś dejavu, widziałem identyczny wątek gdzieś w Javie xD anyway: moim zdaniem gwiazdki nie mają sensu. Szczególnie właśnie kiedy dla jednego dobra znajomość to umiejętność używania bazy jako programista (query, batche, optymalizacje) a dla innego to też kwestie związane np. z indeksami, izolacją, partycjami, a jeszcze dla innego to oznacza głęboką znajomość technikaliów danej bazy.
Znasz coś to piszesz w CV że znasz, a potem na rozmowie rekruter stwierdzi czy umiesz na takim poziomie jaki im potrzebny.

A dla tych którzy uważają ze SQL jest prosty i płytki temat to polecam poczytać sobie artykuły z serii sql injection blacklist bypass :D Z życia wzięte, z CTFa wczoraj: mamy injection w insert into w jednej z wartości (powiedzmy że to rejestracja usera i w username możemy dać ' i mamy injection. Nie ma echo z serwera, sleep, benchmark, rlike i sporo innych keywordów blacklistowane. Trik polegał na tym, że można zrobić inject w stylu:

', ~0 + (0+(select 1 from dual where XXX)) #

Bo w tej sytuacji jeśli XXX jest true to dostaniemy overflow i zapytanie się wywali a my od serwera dosatniemy 500, a jeśli XXX jest false to zapytanie wykona się poprawnie. Na tej podstawie możesz zrobić binsearch i wyciagnąć sobie np. scheme bazy z jakiegoś information_schema a potem zdumpować wartości z bazy...

Większość osób codziennie korzystających z baz danych nawet nie wie, że jak dasz warunek "where kolumna <> 0" to wynik nie wypluje Ci rekordów, gdzie "kolumna" jest nullem (mam nadzieję, że tak jest i nie palnąłem publicznie głupoty), więc "dobra znajomość SQL / Baz danych" znaczy na ogół tyle samo ile "chęć do pracy w dynamicznym zespole".

Znajomość 4/5 to np. wyciągnięcie N-tego rekordu bez użycia: TOP, LIMIT, funkcji okna.

4/5 to umiejętność wyciągnięcia 4 wierszy z 5 wierszowej tabelki

Shalom napisał(a):

dla tych którzy uważają ze SQL jest prosty i płytki temat
Trik polegał na tym, że można zrobić inject w stylu:

', ~0 + (0+(select 1 from dual where XXX)) #

Bo w tej sytuacji jeśli XXX jest true to [........]

Przyjdzie admin, przyjdzie devops, przyjdzie ktoś od styku z biznesem.
Każdy powie, że jego racja, jego triki, jego przypadki są najważniejsze, każdy kto się na tym nie zna to trąba nie programista.
Tylko taki One Man Army jak wszechogarniający expert, reszta: "wam kury szczać prowadzać a nie aplikacje robić".

Później przyjdzie Gajowy z Marketingu i Działu Sprzedaży i wszystkich, Adminów i Security przegoni z biznesowego lasu.

Biznes to jest biznes a nie partyzantka, nie potrzebuje Johna Rambo Perfect One Man Army

Pamiętnik partyzanta:
Poniedziałek: Goniliśmy Niemców po lesie.
Wtorek: Niemcy gonili nas po lesie.
Środa: Goniliśmy Niemców po lesie.
Czwartek: Niemcy gonili nas po lesie.
Piątek: Goniliśmy Niemców po lesie.
Sobota: Niemcy gonili nas po lesie.
Niedziela: Gajowy wyrzucił nas wszystkich z lasu.