Por Kraig Brockschmidt e Lorenz Prem, Gerentes de Programa da Microsoft Corporation
Última atualização: setembro de 2010
Ao longo dos últimos vinte anos, a Microsoft vem desenvolvendo soluções de acesso a dados cada vez mais poderosas e flexíveis. Algumas são muito especializadas, outras de uso geral, mas todas elas compartilham duas metas comuns: fazer com que as aplicações tenham acesso às informações que eles precisam e ajudar os desenvolvedores a gastar menos tempo com os detalhes ligados ao armazenamento de dados e mais tempo criando softwares sofisticados que utilizam esses dados para proporcionar benefícios reais aos seus clientes.
Nessa visão geral do passado, você verá rapidamente que há muitas tecnologias de desenvolvimento de dados diferentes, assim como há muito tipos diferentes de fontes de dados. Algumas tecnologias deixaram de ser usadas, mas a maioria delas ainda está ativa e muitas continuam sendo desenvolvidas. Por que é assim? Por que a Microsoft continua criando meios adicionais de fazer essencialmente a mesma coisa?
Na verdade, a razão fundamental não diz respeito às particularidades de acesso ou manipulação de dados, nem aos detalhes dos bancos de dados. Essencialmente, refere-se ao fato de que os elementos de mais longa duração em praticamente todos os sistemas de computadores são os dados. Não o hardware, não as arquiteturas de design, não a tecnologia de banco de dados nem as APIs de acesso a dados, e certamente não as aplicações construídas sobre as tecnologias de acesso a dados.
Não, os dados sobrevivem a todos eles, porque são os dados que conservam os fatos da nossa existência – bem como das pessoas, das organizações e das nações – e, sendo assim, tais fatos continuarão a ser fatos para sempre. Com certeza esses dados serão migrados de um sistema para outro (e outro, e outro). E talvez sejam atualizados ocasionalmente, como quando alguém nasce, quando alguém muda o nome, ou quando descobrimos que devíamos ter usado quatro dígitos, em vez de dois, para armazenar um ano. Mas, no que diz respeito aos sistemas de computadores, os dados são efetivamente imortais, e tudo o mais não passa de um invólucro. Os sistemas podem ser atualizados ou ficar obsoletos, e talvez um fornecedor de banco de dados faça uma venda melhor do que a concorrência. Seja qual for o caso, os dados se movem o tempo todo... E ainda assim os dados permanecem os mesmos, esperando para ser acessados e colocados em bom uso.
Assim, cada camada que é construída em torno dos dados é cada vez mais efêmera – ou seja, de curta duração – do que as mais próximas a eles. Os dados possuem mais longevidade que o mecanismo de banco de dados que, por sua vez, geralmente sobrevive às tecnologias de acesso a dados. Por exemplo, à medida que você lê este artigo, observe a constância do Microsoft SQL Server nas ilustrações: ela permanece onde está no canto inferior direito, sobrevivendo às suas tecnologias de acesso a dados originais, bem como provavelmente irá sobreviver às atuais e às que estão neste instante em desenvolvimento.
É óbvio que essas tecnologias de acesso a dados, por sua vez, sobrevivem a aplicações específicas construídas sobre elas. Outra maneira de afirmar isso é que as tecnologias de acesso a dados específicas funcionam como um meio especial de construir aplicações – como um código Win32 não gerenciado ou um código .NET gerenciado – ou um tipo particular de aplicação – como um cliente avançado, um aplicação Web ou uma aplicação para servidores. Portanto, naturalmente possuem uma maior expectativa de vida do que qualquer aplicação (da mesma forma que as aplicações possuem uma maior expectativa de vida do que as formas com que se apresentam ao usuário, que mudam facilmente de uma versão para outra).
As tecnologias de acesso a dados vêm, e ocasionalmente vão, simplesmente porque se adaptam às necessidades de desenvolvimento que cercam os diferentes tipos de aplicações e os diferentes tipos de repositórios de dados. É por esse motivo que há tecnologias para o código (.NET) gerenciado e (Win32) não gerenciado, e tecnologias que servem para aplicações que precisam desconhecer o banco de dados, bem como para aplicações que precisam ser otimizadas para uma fonte especial. É realmente apenas uma questão de descobrir qual método é mais adequado aos seus requisitos em particular. (Para obter um guia conciso de seleção para todas as tecnologias que atualmente possuem suporte, consulte a
página Saiba Mais do
Data Developer Center.)
Junto com as tecnologias de acesso a dados, começaram a aparecer os serviços de suporte. Aparentemente, toda empresa precisa de relatórios, análise e outros serviços para dar continuidade aos dados contidos nos bancos de dados implantados em toda a empresa. A princípio, esses recursos de suporte não existiam, ou existiam em uma versão muito limitada. Com o passar do tempo, os recursos melhoraram. Junto com eles, cresceu o valor que podia ser obtido dos dados armazenados nos bancos de dados. Os dados também irão sobreviver a esses serviços, mas os serviços continuarão a agregar cada vez mais valor ao modelo de banco de dados.
Um Breve Aceno ao Microsoft Access
No início da década de 1990, a Microsoft possuía duas ofertas básicas de bancos de dados: o SQL Server e o Access. O Microsoft Access era e continua sendo uma combinação fabulosa de um mecanismo de banco de dados e um ambiente com design front-end, permitindo o rápido desenvolvimento de aplicações de bancos de dados completas sem as tradicionais práticas de codificação. Mas isso é tudo que iremos dizer sobre o Access aqui, porque com uma solução como o Access, você realmente não precisa se preocupar com a mecânica de comunicação com um banco de dados. O Access faz isso sem a necessidade de intervenção do usuário. E mais, como uma solução cliente para desktop, o Access visa apenas uma parcela das aplicações de banco de dados que as pessoas querem criar; muitas aplicações realmente precisam se focar em alcançar os dados diretamente.
Isso era realidade com o SQL Server desde o início, que por si mesmo consistia no acesso a dados de alto desempenho adequado para um grande número de usuários simultâneos. Seu foco era fornecer os dados a quaisquer aplicações que precisassem obtê-los, não importando como tais aplicações fossem escritas. Nesse sentido, pouca coisa mudou ao longo dos anos, exceto que a paisagem das fontes de dados se expandiu muito, os tipos de aplicações de banco de dados são muito mais variados e os meios dessas aplicações se comunicarem com as fontes de dados têm se desenvolvido constantemente, como uma pequena comunidade com poucas casas cresce e se desenvolve até se tornar uma cidade completa. E é essa história especial de crescimento que coloca todas as tecnologias de desenvolvimento de dados da Microsoft em um contexto.
Os Fundamentos do Desenvolvimento de Dados: Tecnologias ("Nativas") Win32
Quando a Microsoft introduziu pela primeira vez o SQL Server 1.0 em 1989, havia uma única API programática ou de “nível de chamada” com o nome de DB-Library. Por meio das suas 150 funções, uma aplicação de console MS-DOS ou OS/2 ou uma aplicação gráfica Windows ou OS/2 podia se divertir com os dados por meio de operações do tipo criar-recuperar-atualizar-excluir que ainda hoje conhecemos e adoramos (a que ironicamente nos referimos através do maravilhoso acrônimo CRUD).
Estava disponível também o
Embedded SQL for C (ESQL for C, de forma resumida), um pré-compilador que permitia as instruções SQL diretamente no código-fonte, um prenúncio simples do que veríamos mais tarde no LINQ. (Se tiver interesse, um exemplar básico do código ESQL for C pode ser encontrado na
documentação do SQL Server 2000.)