Respostas:
Eu acho que você está tentando viver no mundo dos sonhos de Joe Celko, onde você só pode usar o SQL padrão e, em qualquer semana, pode ser necessário portar todo o seu código do SQL Server para o Oracle e, em seguida, do Oracle para o DB2 e depois voltar para o SQL Server novamente . Duas vezes.
Embora os aspectos principais e fundamentais do SQL padrão o ajudem em qualquer lugar, tentar limitar-se a esse conjunto de idiomas por medo de futuras portagens (ou apenas por princípio) não é um caminho que eu recomendaria. Pessoalmente, eu adiro ao padrão ANSI quando posso (por exemplo, <> vs.! =, COALESCE vs. ISNULL, CURRENT_TIMESTAMP vs. GETDATE () etc.), mas também não tenho medo de usar o SQL Server específico coisas que facilitam meu trabalho.
É importante entender como o SQL funciona em geral; é igualmente importante entender como o idioma funciona no (s) seu (s) RDBMS (s) - incluindo desvios do padrão, desvios da maneira como outro RDBMS pode ter implementado o mesmo conceito e extensões proprietárias que não existem em outros lugares.
O SQL Server, por exemplo, cobre uma boa parte do padrão e fica mais próximo da total conformidade com cada nova versão. Será que nunca vai cobrir 100%? Altamente duvidoso. Continuará a adicionar extensões proprietárias que não estão no padrão? Certamente. Se todo mundo cobrisse o padrão e ninguém saísse dele, não haveria vantagens em escolher uma plataforma em vez de outra, e todos estaríamos usando a mesma coisa.
Nenhum deles. Você pode aprender SQL (-ish) padrão para qualquer RDBMS.
O SQL padrão não é usado no mundo real para pagar trabalhos em projetos de sucesso ...
Dizendo isso, o MySQL é um bom lugar para começar e aqui está um tutorial
constructive guidance incrivelmente hipócrita. Onde está sua orientação construtiva aqui para o gbn melhorar sua resposta?
Todos os principais RDBMSs suportam as diferentes versões da especificação SQL em diferentes graus, com as versões mais antigas da especificação mais totalmente suportadas. Nem todos levam a conformidade igualmente a sério (por exemplo, a Oracle começou a oferecer suporte a 'ansi joins' em 2001, quase uma década após o SQL-92 ) e, como o @gbn já disse, na prática, você precisa conhecer o sabor do SQL usado por cada produto você usa.
O Postgres é uma exceção, pois "se orgulha da conformidade com os padrões" . Para "fins de aprendizado e referência", você precisa de prática prática com um banco de dados, não apenas conhecimento de um livro ou padrão, e o postgres é uma plataforma ideal para aprender as cordas porque:
Concordado com Jack e gbn, não há um padrão e você precisa fazer uma escolha. Para fazer essa escolha, você precisa selecionar o RDBMS primeiro. Eu recomendo pensar nas seguintes coisas: 1) você quer ser desenvolvedor de banco de dados ou DBA? 2) Com quais sistemas operacionais você deseja trabalhar? Eu concordo, essa pergunta é um pouco estranha, mas quando falo com os alunos, eles dizem que é importante.
Por exemplo (apenas exemplo, talvez eu esteja errado) se você quer ser um DBA e não quer trabalhar com o Windows, não precisa pensar no MSSQL. E se você quer ser DBA e gosta de trabalhar com cadeia de comando e arquivos de configuração - talvez o Oracle seja o que você precisa. Se você quer ser desenvolvedor, quer usar seu conhecimento em projetos freelancers, talvez precise do MySQL?