Przejście z postgresql na ms sql

Witam,
zwracam się z zapytanie do osób, które miały mozliwość pracować w obu środowiskach wymienionych w temacie.
Dostałem propozycję ciekawej współpracy przy tworzeniu bd, będąc jeszcze na studiach, lecz jest ona w oprogramowaniu postgresql, a ja sercem pozostaje z ms sql'em. Pytanie brzmi czy nowe funkcje których nauczyłbym się w pracy w postgres'em ciężko mi będzie w przyszłości zamienić na pracę w ms sql'u. Pytam zarówno o kwestie administracyjne backupy etc jak i tworzenie kodu.
W przyszłości wiem, że chcę pracować w ms sql'u i zastanawiam się czy obecna oferta w jakimś stopniu może przyczynić się do rozwoju w tym zakresie, mimo innego oprogramowania

Na codzień pracuje z sql serverem, ale cyklicznie spotykam się z innymi silnikami. Moim zdaniem poznanie nowej bazy wyjdzie Ci na plus. Nie wzbogaci to Twojej znajomości MS, ale da niezłą perspektywę.

Wszystkie SQL owe bazy danych są takie same - drobnostki składniowe, dodatkowe narzędzia, sterowniki się różnią. Administrowanie jest oczywiście zupełnie inne, ale jak się dowiesz kiedy używać b-tree, kiedy r-tree a kiedy indeksów klastrowych to będziesz mógł to wykorzystać na dowolnej platformie.

piotrpo napisał(a):

Wszystkie SQL owe bazy danych są takie same - drobnostki składniowe, dodatkowe narzędzia, sterowniki się różnią.
chyba kpisz albo nie miałeś styczności z czymś więcej niż select/update/delete w więcej niż jednej bazie. To tak jakbyś powiedział, że c# od c++, javy czy php różni się drobnostkami składniowymi i dodatkowymi narzędziami.

SQL jako sam SQL (czyli select/update/delete) jest w większości baz taki sam - w końcu to niby standard. Ale w jednej "dziwne" nazwy bierzesz w [] w innej w "" w jeszcze w ``. W jednej przy funkcjach agregujących pozostałe pola musisz umieścić w group by w innej nie. Różne bazy różnie mają rozwiązane autoinc. A to co wymieniłem to jest jak na razie "standard SQL". Następnie wykraczamy poza "standard" i mamy procedury, triggery (choćby fakt, że mssql nie ma wyzwalaczy before).

Prawdą jest, że jak znasz jedną bazę "na wylot" to poradzisz sobie z każdą (analogicznie jak jesteś dobry w jakimkolwiek języku obiektowym to poradzisz sobie w każdym innym) ale już problemy będziesz miał z zadaniami, które wymagają użycia specyficznych funkcji.

BTW uważam, że postgres jest dużo przyjemniejszy od mssqla :p.

Wiadmo, że obie bazy się od siebie różnią, oczywiście jestem tego w pełni świadomy ;). Bardziej chodziło mi czy te różnice są tak zasadnicze, że fakt iż nauczę się teraz postgresa na bardziej zaawansowanym poziomie nie przyniesie żadnych korzyści podczas nauki SQL servera za pól roku/rok. Ciężko mi to dobrze wytłumaczyć ale w skrócie po tej pracy w postgresie chce ruszyć do pracy w ms sqlu i pytanie czy będzie mi łatwiej dzięki postgresowi, czy mimo wszystko będzie to nauka od 0 bo różnice są zasadnicze. Jak już wspomniałem mam na myśli zarówno aspekty języka proceduralnego jak również funkcji administracyjnych - np rodzaje backupów obu programów są kompletnie inne itp itd

abrakadaber napisał(a):

chyba kpisz albo nie miałeś styczności z czymś więcej niż select/update/delete w więcej niż jednej bazie. To tak jakbyś powiedział, że c# od c++, javy czy php różni się drobnostkami składniowymi i dodatkowymi narzędziami.

I po co te personalne wycieczki?

SQL jako sam SQL (czyli select/update/delete) jest w większości baz taki sam - w końcu to niby standard. Ale w jednej "dziwne" nazwy bierzesz w [] w innej w "" w jeszcze w ``. W jednej przy funkcjach agregujących pozostałe pola musisz umieścić w group by w innej nie. Różne bazy różnie mają rozwiązane autoinc. A to co wymieniłem to jest jak na razie "standard SQL".

Następnie wykraczamy poza "standard" i mamy procedury, triggery (choćby fakt, że mssql nie ma wyzwalaczy before).
No tak, to czy napiszemy "autoinc", czy użyjemy takiej lubi innej sekwencji robi wielka różnicę. Tak - jest różnica pomiędzy tSQL i plSQL i paroma innymi dialektami. Czasami nie masz jakiegoś typu wyzwalacza, albo inaczej działają transakcje, są dodatkowe funkcje, albo ich brakuje. Tylko że zabawa bazami danych zaczyna się od normalizacji, pisania zapytań i ogarnięcia co to jest wyzwalacz, widok, tabela, widok zmaterializowany, indeks i jakie są jego rodzaje, co to jest transakcja i poziom izolacji, czym są statystyki i do czego służą, a to że gdzieś się używa pojedynczych, podwójnych ciapek, czy kwadratowych nawiasów jest rzeczą kompletnie wtórną. Podobnie jak np. rzutowanie stringa na datę czy inne pierdoły które można odnaleźć w 5 minut w dokumentacji. Wprowadzony w mySQL błąd z klauzulą group by raczej nie przeszkodzi w używaniu tego silnika komuś, kto już wie że tak nie należy robić i dlaczego.

Taka drobnostka - spróbuj do pola autoinc wstawić własne wartości w dwóch tabelach. W obu bazach. W każdej sie da ale bardzo inaczej...

@Panczo, @abrakadaber, @Marcin.Miga może trochę z innej strony zapytam, polecicie jakieś środowisko graficzne do postgresa? Bo jak dla mnie to przesiadka z SSMS na pgAdmina(a na niego chyba najczęściej pada wybór) to jest masakra, szczególnie na wersję 4 :D Czasem muszę jakieś proste selecty zapuścić na postgresie, a jak odpalam pgAdmin4 to mnie aż skręca :P Jak dla mnie jest bardzo toporny w porównaniu z Management Studio

piotrpo napisał(a):

No tak, to czy napiszemy "autoinc", czy użyjemy takiej lubi innej sekwencji robi wielka różnicę. Tak - jest różnica pomiędzy tSQL i plSQL i paroma innymi dialektami. Czasami nie masz jakiegoś typu wyzwalacza, albo inaczej działają transakcje, są dodatkowe funkcje, albo ich brakuje. Tylko że zabawa bazami danych zaczyna się od normalizacji, pisania zapytań i ogarnięcia co to jest wyzwalacz, widok, tabela, widok zmaterializowany, indeks i jakie są jego rodzaje, co to jest transakcja i poziom izolacji, czym są statystyki i do czego służą, a to że gdzieś się używa pojedynczych, podwójnych ciapek, czy kwadratowych nawiasów jest rzeczą kompletnie wtórną. Podobnie jak np. rzutowanie stringa na datę czy inne pierdoły które można odnaleźć w 5 minut w dokumentacji. Wprowadzony w mySQL błąd z klauzulą group by raczej nie przeszkodzi w używaniu tego silnika komuś, kto już wie że tak nie należy robić i dlaczego.

Nie chce wyjść na idiotę, ale nie znam połowy tych rzeczy które wymieniłeś, więc muszę spytać bo nie rozumiem do końca Twojej wypowiedzi. Opowiadasz się za stroną która mówi iż różnice między obiema bazami są diametralne czy też za taką która mówi, że przejście z 1 bazy na 2gą, mając w głowie wiedzę jak to działało w poprzedniej bazie i kiedy było używane, jest w miarę proste?

Uważam, że jeśli pytasz o początki nauki z bazami danych to nie ma znaczenia jakiego konkretnego serwera używasz - to czego się nauczysz będzie przydatne na większości innych. Wyjątkiem jest wiedza jak się nazywa konkretna funkcja - np. na części serwerów pierwszy nie-null jest zwracany przez coalesce(.....) a na innych przez nvl(). Jeden serwer założy na kluczu głównym domyślnie indeks klastrowy a inny b-tree, czy masa innych drobiazgów. Tylko jeżeli wiesz jak działa baza danych, to opanowanie tych różnic to przeczytanie dobrej książki do konkretnego silnika. Liczbowo, w czasie nauki - 90% jest wspólne, 10% specyficzne dla konkretnych serwerów. Jeśli masz możliwość wzięcia udziału w ciekawym projekcie, w dziedzinie, która cię interesuje to bierz - na 100% ucząc się programować PostgreSQL nabędziesz wielu umiejętności przydatnych przydatnych w programowaniu na dowolny inny serwer SQL.