Witajcie serdecznie. W co Waszym zdaniem na dzień dzisiejszy warto bardziej zainwestować, jeżeli chodzi o naukę i ścieżkę kariery: SQL czy SAP? Dodam, że nie mam żadnego doświadczenia, a wykształcenie mam ekonomiczne. Trochę już SQL ogarniam, ale według mnie jeszcze za mało na wysyłanie CV. Liczę na cenne rady. Dzięki.
SQL 
- Rejestracja:około 4 lata
- Ostatnio:ponad 3 lata
- Postów:9
0
sql to mały temat na pare tygodni nauki, juz w szczegolnosci przy sapie
na samym sqlu nie zbudujesz kariery w it chyba ze chodzi ci o stanowisko typu wybieranie danych i robienie raportów i prognoz to wtedy pomyliles fora
- Rejestracja:ponad 6 lat
- Ostatnio:3 dni
- Lokalizacja:Silesia/Marki
- Postów:5505
0
Tony Harris napisał(a):
na samym sqlu nie zbudujesz kariery w it chyba ze chodzi ci o stanowisko typu wybieranie danych i robienie raportów i prognoz to wtedy pomyliles fora
Programiści PgSQLa/PLSQLa jednak istnieją. Chociaż to chyba wymierający gatunek?
- Rejestracja:prawie 5 lat
- Ostatnio:28 dni
- Postów:65
1
adams0 napisał(a):
Jak to jest z tym wymieraniem programistów SQL?
W sensie wszystko się przenosi do MongoDB ?
Nie do końca. Owszem, odwrót od Oracle'a jest zauważalny, ale to nie jest że ot tak nagle Oracle przestanie być używany. Jest mnóstwo olbrzymich aplikacji (chociażby od IBM czy właśnie SAP-a) które używają Oracle i są certyfikowane na ten konkretny RDBMS. Olbrzymie korporacje używają aplikacji właśnie od tych vendorów. Przepisanie ich na inny silnik to zbyt kosztowne i czasochłonne zajęcie. Co więcej, nie wszystko da się przepisać na NoSQL i moim zdaniem, w najbliższej przyszłości RDBMS nie wymrze.
PL/SQL Developer może zarabiać mniej niż tradycyjny programista np. Java ale raczej pracy dla niego nie powinno zabraknąć. Może być jej mniej i większa konkurencja na rynku, ale z pewnością będzie.
P.S. Zajmuję się właśnie bazami danych zawodowo, więc od kilku lat "siedzę" w tej branży.
- Rejestracja:ponad 4 lata
- Ostatnio:ponad 3 lata
- Postów:208
2
Generalny trend jest taki że rezygnuje się z dużych centralnych baz danych do których się łączy pół firmy w kierunku tego że każda aplikacja ma swoją bazę - te bazy są mniejsze, mniej krytyczne, wymagają mniej wiedzy do operowania (zwłaszcza jeśli to coś zarządzane typu AWS RDS), łatwiej ogarnąć w całości ich model i można dostosować je do potrzeb konkretnej aplikacji (np trzymać dane w DynamoDB a nie w Oraclu jeśli ten kv/dokumentowy model ci bardziej pasuje).
Kolejnym trendem jest przenoszenie wszelkiego rodzaju logiki z triggerów i stored proców z bazy do aplikacji - po części stąd że ma się wszystko w jednym miejscu i łatwiej tym zarządzać (kontrola wersji itp), po części z tego że imperatywne języki w bazach są dość nieprzyjemne i developerzy ich unikają. Minusem jest oczywiście spadek wydajności przez round tripy po sieci (który czasami ma znaczenie) i utrudnienie migracji w przypadku kiedy powstanie nowy system który zastępuje aktualną implementację - trzeba wykorzystać change data capture lub inne metody.
Te dwa trendy ograniczają potrzebę na zespół DBAów, często widzi się DBAów jako mobilnych konsultantów którzy sobie skaczą z aplikacji do aplikacji i pełnią funkcję doradczą raczej niż ownerów danych. Oczywiście to tylko trendy - firmy które mają centralnego Oracla będą się z niego migrować latami (tak jak np Amazon który rzucił na to mnóstwo zasobów) bo nie jest to trywialne (masz problemy takie jak ownership danych, eventual consistency, zestawienie reportingu z tej floty serwisów - a to tylko czubek góry lodowej).
Tak czy siak z wykształceniem ekonomicznym możesz spróbować pójść bardziej w stronę Business Intelligence - pracowałbyś wtedy z bazami do raportów, produkował z danych jakieś wnioski, robił wizualizacje. Sam SQL to tego nie wystarczy, ale to chyba nie taki zły pierwszy krok.
edytowany 1x, ostatnio: Zing
- Rejestracja:prawie 5 lat
- Ostatnio:6 miesięcy
- Lokalizacja:Warszawa
- Postów:169
1
Zing napisał(a):
Tak czy siak z wykształceniem ekonomicznym możesz spróbować pójść bardziej w stronę Business Intelligence - pracowałbyś wtedy z bazami do raportów, produkował z danych jakieś wnioski, robił wizualizacje. Sam SQL to tego nie wystarczy, ale to chyba nie taki zły pierwszy krok.
Sam SQL jak najbardziej wystarczy zeby sie zalapac do BI na jakiegos juniora. Reszty nauczysz sie juz w pracy, bo to co i jak analizujemy zalezy po czesci od branzy. Rowniez polecam isc w te strone. Studia ekonomiczne daja dobre podstawy pod ten kierunek.
- Rejestracja:prawie 4 lata
- Ostatnio:prawie 4 lata
- Postów:1
0
No dobra, a co powiecie na taką ścieżkę:
SQL DEV ---> PL/SQL DEV ---> DWH/ETL DEV
Niedługo będę wchodził już na naukę PL/SQL, bo z samym SQL to wiem, że nie zawojuję nigdzie. Chcę dobrze umieć SQL i chociaż podstawy PL/SQL i dopiero zacząć wysyłać CV. Co o tym powiecie? Dobry plan? Przyszłościowa ścieżka?
PS. Co do BI to myślałem też nad tym, ale podjąłem decyzję, że wolę chyba jednak iść w ETL. Czy jest to decyzja słuszna? Nie wiem. Dziękuję jednak za wskazówki odnośnie BI, nie wykluczam, że jak mi nie pójdzie z PL/SQL to pójdę w BI. Koniec końców SQL i tak i tak musi być dobrze ogarnięty.
edytowany 1x, ostatnio: gregory100144
- Rejestracja:prawie 5 lat
- Ostatnio:6 miesięcy
- Lokalizacja:Warszawa
- Postów:169
0
Przeciez mozesz robic ETL pracujac w BI. BI to bardzo szeroki temat. Po drugie ta sciezka nie dokonca moze tak wygladac. Mozesz od razu sie zalapac na jakiegos Junior ETL Dev. Naucz sie tego SQLa, zacznij wysylac CV, a reszte zweryfikuje zycie/rynek.