Guardar objetos no banco de dados é um dilema : Podemos guardar no banco de dados a referência para o local onde o objeto se encontra e nesse caso a aplicação precisará ter acesso ao caminho indicado pela referência, além do fato de que a manipulação do elemento não sofre controle do banco de dados; ou guardamos o objeto em um campo blob da base de dados, ganhando os controles do banco e uma independência de local (o banco entrega o blob), mas passando a responsabilidade de controle de um grande blob para a base de dados.
O SQL Server 2008 traz um meio termo : poder usar os recursos do banco de dados para gerenciar os blobs, mas o banco de dados não usará sua estrutura de armazenagem para guarda-los e sim o sistema de arquivos.
Isso é feito com um fileGroup criado especialmente para a armazenagem de filestreams e com um "arquivo" que na verdade não é um arquivo, mas um direcionamento para uma pasta do sistema.
Assim sendo a aplicação lida com a informação mantendo seu isolamento de localização (o banco entrega o blob), mas o banco não sofre as consequencias de gerenciar o blob em seu formato, joga o blog para o sistema de arquivos e controla isso lá. Quer dizer : O melhor dos dois mundos.
No post sobre a instalação do SQL Server citei que o recurso de fileStream não só precisa de de permissão a nível de servidor, como esta permissão é dada em separado para o acesso via T-SQL ou o acesso via streaming.
O acesso via T-SQL é simplesmente como o acesso de um blob, ficando totalmente transparente para a aplicação o fato do blob ser um arquivo em disco. Mas e o acesso via streaming ?
Essa pergunta do acesso via streaming nos leva a uma questão que muitos tem feito : "O que acontece se o arquivo for acessado diretamente via file system, ao invés de através do banco ?"
Ocorre que via fileSystem o seguinte acontecerá :
- Os nomes dos diretórios e arquivos são baseados em uma chave única de tabela que é um GUID, ficando algo ininteligível
- O SQL Server travará os arquivos que estiver manipulando
- Os arquivos não ficam exatamente da forma como foram passados, são divididos em pedaços, sendo ilegíveis individualmente
Com isso vemos que o acesso via disco não é o caminho, ainda mais porque voltariamos para cenários em que a aplicação dependeria de ter um acesso físico ao caminho de disco. Então o que significa o acesso streaming ?
Foi criada uma API, chamada OpenSQLFileStream, que faz a abertura de um FileStream (não necessariamente de forma literal) pelo SQL Server, através da conexão com o banco.
Mas como assim API ? API do sistema operacional ?
API não são apenas aquelas funções chatas de serem utilizadas no sistema operacional. API é a abreviação de Application Programable Interface, portanto o termo API significa a interface programável para interagir com uma aplicação, seja ela qual for, neste caso, o SQL Server.
Assim sendo, a função OpenSQLFileStream da qual estamos falando é uma função localizada dentro da DLL do client do SQL Server.
Essa função, por sua vez, requer o uso de um recurso dos tipos filestream (pathname) para a identificação do nome que o filestream possui fisicamente (não que a aplicação precise de acesso físico ao local do arquivo) para que o filestream seja aberto.
Todo esse conjunto é obrigatoriamente executado dentro de uma transação de banco, para garantir a integridade do filestream em conjunto com os demais dados do registro da tabela.
O resultado da função OpenSQLFileStream é um handle de arquivo compatível com win32, o que permite a aplicação seguir sua execução com este handle como se fosse um stream de arquivo normal.
Mas por que, podendo acessar tudo como um blob, fazer um acesso como se fosse um filestream ?
Só vejo um motivo até agora : compatibilidade com código legado escrito para aplicar regras de negócio sobre um filestream
Vejam um link sobre esse assunto em : http://msdn2.microsoft.com/en-us/library/bb933972(SQL.100).aspx
Como vocês observarão, isso está bem em baixo nível ainda. Com certeza até o lançamento do SQL Server 2008 teremos melhorias neste tópico.
© Copyright 2006-2010