Seja um mestre SQL, padawan!

Projeto: Documentação completa de SQL para consulta

Trabalhe com bancos de dados relacionais: Dúvidas Frequentes e Suporte

Confira abaixo algumas respostas para perguntas comuns sobre banco de dados.

• Qual SQL eu deveria aprender?

  Apesar de ter uma versão padrão, a ANSI que é comum a todos os SGBDs, o SQL pode receber novas funcionalidades de acordo com o distribuidor do banco de dados.

  Por exemplo, no T-SQL, ou Transact-SQL, existem funções de data como DATEPART, DATEADD e DATEDIFF que podem não funcionar fora do SQL Server e Sybase. De igual forma o Oracle, MySQL, Postgres, e outros, tem também suas funções exclusivas.

  O que se recomenda é que se aprenda e domine o SQL ANSI. Embora com apenas com ele tenhamos mais trabalho para realizar algumas tarefas, fica a certeza de que o código SQL escrito poderá ser executado em qualquer lugar.

  Ainda assim é importante considerar a política da empresa, pois se você tiver a oportunidade de otimizar suas consultas a partir dos recursos presentes do banco de dados utilizado é recomendado fazê-lo, aprendendo quais foram as adições feitas ao SQL pelo distribuir desse SGBD.

• Quando eu não deveria utilizar ORM?

  Tentar adaptar o forma orientada a objetos de pensar uma aplicação ao modelo relacional não é uma tarefa intuitiva. Como reflexo disso, diversos padrões, arquiteturas e técnicas têm sido apresentadas à comunidade procurando resolver essa questão.

  Uma das mais aceitas atualmente é a ORM, mapeamento objeto/relacional. Com ela podemos nos preocupar mais com a modelagem da aplicação e menos com os dados gerados durante a sua execução.

  Embora essas seja a solução mais aceita, ela não deixa de gerar discordâncias. Há quem defenda o uso do SQL, sem a ORM em aplicações, pois dessa forma ganha-se performance. Em contrapartida, ao usarmos a ORM ganhamos agilidade no desenvolvimento. O que fazer, então?

  Quando optamos pela ORM estamos delegando ao framework a tarefa de gerar as consultas e com isso perdendo o controle sobre elas. Portanto, considerando que existam recursos limitados de hardware ou mesmo um apelo para a otimização, a ORM não é indicada.

  Em casos assim, seria mais prudente desenvolver uma pequena solução de acesso a dados utilizando algum padrão de projeto, como Mapper ou DAO.

• O SQL corre o risco de obsolescência?

  Sinceramente, acreditamos que não :)

  Mesmo Frameworks ORMs como Doctrine ou Hibernate são feitos com SQL. Eles são interfaces a partir das quais podemos nos comunicar com o banco de dados de forma mais fácil, mas são construídos utilizando a mesma lógica utilizada nessa linguagem.

  É certo que o hardware tem se tornado cada vez mais barato e, por conta disso, a otimização das consultas tem se tornado uma preocupação menor. Porém, conforme a aplicação for crescendo, essa será uma preocupação, principalmente até que ela possa ser escalonada.

  Com o tempo os Frameworks ORM também tem evoluído para tornar melhor o SQL gerado, mas isso não quer dizer que o SQL esteja se tornando menos importante com o tempo.