Quando comecei a ler o livro, confesso que estava expectante, a pensar: será este apenas mais um livro técnico sobre Microsoft SQL Server?
Demorei algumas páginas até formalizar uma opinião mais concreta! Na realidade não é apenas mais um livro, é um excelente livro, que aborda de forma simultaneamente simples e detalhada, diversos aspectos do MS SQL Server 2012 que apesar de serem de grande utilidade numa boa parte das implementações de software são descurados, ou passados para “segundo plano”, levando o programador a “repetir trabalho” que já existe feito, ou existe forma mais simples de o fazer.
Nas últimas duas edições, abordámos o tema da optimização de SQL com o recurso a técnicas de melhoria do código SQL. Recorremos, nomeadamente, à utilização de bind variables e à correcta implementação de índices. Nesta edição, vamos apresentar uma das ferramentas de diagnóstico que permitem prever e verificar a optimização: os planos de execução.
O que é
Antes de efectuar um SELECT na base de dados, o optimizador traça um plano de execução, de modo a avaliar que dados recolher, onde e como os deve obter. O plano de execução é influenciado por múltiplos factores e varia ao longo do tempo, isto é, varia consoante o estado presente da base de dados.
A correcta gestão de acessos concorrentes e transacções são tarefas muito importantes numa aplicação. A arquitectura da DLINQ (LINQ para SQL) já nos fornece uma implementação base preocupada com estes aspectos, mas também permite que o programador personalize essa implementação de modo a adaptá-la às necessidades da sua aplicação.
Não sendo o objectivo deste artigo explicar a base do funcionamento da DLINQ é necessário explicar alguns conceitos mais básicos do seu funcionamento de modo a enquadrar os leitores com menos contacto com esta linguagem/tecnologia. De modo a cumprir esse objectivo iremos falar, ligeiramente mais à frente, sobre a classe DataContext.
Nos dias que correm, são muitos os que já se aventuraram no desenvolvimento de aplicações web-based. Quando essas aplicações começam a ganhar notoriedade, há uma grande possibilidade de serem usadas noutro ambiente diferente daquele em que sempre desenvolvemos. Um dos problemas comuns é o facto de termos de usar um software de gestão de base de dados (SGDB) diferente e, como escrevemos a aplicação para usar um determinado SGDB, somos obrigados a modificá-la para podermos utilizar outro. Para evitar estes incómodos, existem bibliotecas que servem de camada de abstração de SGDBs.
O que é uma camada de abstracção?
Uma camada de abstracção é simplesmente um elo de ligação entre uma aplicação e dados externos (sejam bases de dados, documentos de texto, etc). Ou seja, a aplicação não liga directamente aos dados externos, mas faz um pedido à camada de abstracção e esta, por sua vez, faz o pedido aos dados, independentemente do seu tipo. A classe ADOdb tem precisamente essa função, é precisamente igual escrevermos uma aplicação que use um determinado SGBD ou outro, o resultado será sempre igual e, as alterações mínimas.