Estou tentando o meu melhor para elaborar minha pergunta da forma mais direta e clara possível. Então, vou começar citando este tópico de resposta dizendo que,
Se você quiser ler e gravar dados FILESTREAM do Windows, clique em Habilitar FILESTREAM para acesso de streaming de E/S de arquivo.
Na minha máquina, configurei com sucesso o FILESTREAM com o SQL SERVER e já processei dados da tabela para a API, mas estou me perguntando o que " Habilitar FILESTREAM para acesso de streaming de E/S de arquivo " pode fazer em termos de otimização de desempenho.
Dadas estas configurações:
A questão principal aqui é: isso introduz diferentes acessos e recuperação de dados entre o ponto de solicitação e o local do arquivo?
O que quero dizer é que, se eu consigo gerenciar os dados do FILESTREAM no SQL Server sem essas configurações mencionadas, essa configuração oferece o mesmo controle sobre os dados que serão responsáveis por acessar quando houver uma solicitação dos dados do arquivo correspondente?
Ainda não vi se é útil ou não, mas acho que tem potencial utilidade no meu caso de uso... No entanto, meu principal objetivo aqui é otimizar o desempenho sem sacrificar o controle granular e a capacidade de gerenciamento entre os dados do arquivo e o destino do aplicativo (API ou algo assim).
Não, essas configurações são especificamente para permitir acesso a dados de filestream utilizando APIs do Windows e aplicativos cliente para lidar diretamente com os dados. Elas permitem um caminho de acesso diferente, por exemplo , para um aplicativo que pode precisar adicionar arquivos grandes que são gerados (como um arquivo de vídeo), mas que não interagem diretamente com o SQL Server.
A menos que você esteja escrevendo seu próprio aplicativo cliente para acessar dados de filestream diretamente para uso em outras APIs do Windows, isso não faz absolutamente nada. Não altera os caminhos de acesso do SQL Server, não acelera nada, não altera como o mecanismo de banco de dados funciona.