Como mover imagens do banco de dados para o sistema de arquivos

Question

Portanto, atualmente, em nosso sistema, armazenamos arquivos de imagem no banco de dados (SQL Express 2005). Infelizmente, não foi percebido que isso alcançaria o tamanho máximo do banco de dados permitido pela Licença do SQL Express. Então eu propus um plano de armazenar as imagens no sistema de arquivos e apenas indexar onde o arquivo está no banco de dados.

O plano é salvar o caminho raiz em nossa Tabela de Opções como algo como ImagesRoot e, em seguida, salvar apenas o ID da imagem real na tabela, que é basicamente um FK da PK do registro com a imagem. Eu determinei que seria melhor dividir isso em subdiretórios dentro do ImagesRoot com base em cada 1000 imagens, então basicamente (ImagedID / 1000) \ (ImageID% 1000) (por exemplo, ImageID é 1999, seria em % ImageRoot% \ 1 \ 999).

Estou à procura de potenciais armadilhas deste sistema e de qualquer coisa que possa ser melhorada, pois já estou a receber alguma resistência por parte do proprietário da empresa que quer que tudo esteja nas bases de dados. Nesse sentido, eu também levaria razões por que tudo deveria estar em bancos de dados.

Devo mencionar que já existem backups automatizados que são executados para todos os bancos de dados de nossos clientes e quaisquer arquivos gerados por nosso programa que precisam ser salvos durante um período de tempo. Eles são opcionais, mas se alguém não for usando nosso sistema, espera-se que eles estejam usando seus próprios ou a perda de dados não é problema nosso (é se o nosso sistema falhar e eles estiverem usando!).

Obrigado

Editar

Algumas pessoas sugeriram usar o 2008 R2 como uma possível correção para isso. É uma boa ideia eu só vou ter que olhar para questões envolvendo programas legados que usam esses bancos de dados. Nem todos usam Procedimentos Armazenados e alguns não são muito amigáveis à manutenção.

    

Answer 1

Se você vai quebrar a estrutura de diretórios assim (e você deve), você não deve usar o método que você propõe, que estará sujeito a clustering. Você deve implementar o mesmo conceito, mas com base em um valor com hash do nome do arquivo.

Por exemplo, ao invés do que você propõe, faça um hash do nome do arquivo (eu usarei md5), então criei os subdiretórios baseados no valor do hash:

Your proposal:
FILE=1999, H1=1, H2=999, FILEPATH=1999
FILE=1998, H1=1, H2=998, FILEPATH=1898
FILE=1997, H1=1, H2=997, FILEPATH=1797

Hashed solution:
FILE=1999, MD5=2554fe5cd0a1b3fb7f9ec112fd326744, H1=2, H2=54, FILEPATH=299
FILE=1998, MD5=82ec15656dd2b8a3e50ff36643a713ad, H1=8, H2=2e, FILEPATH=8e98
FILE=1997, MD5=9cc2e1e538bd538014d294138a85e20b, H1=9, H2=cc, FILEPATH=9\cc97

A vantagem de fazer isso é que ele espalha a utilização das pastas de maneira mais uniforme, permitindo que você faça coisas como espalhar as pastas pelas unidades para obter desempenho, etc.

É provável que o seu banco de dados tenha funções hashing embutidas, o que permitiria calcular o caminho na hora, você também poderia facilmente calculá-lo uma vez no código e salvar todo o caminho.

Meu exemplo de MD5 pode não ser o padrão (acho que SHA1 é mais comum), mas foi apenas para obter um exemplo de trabalho por aí.

    

Answer 2

A principal razão para colocar todas as coisas (principalmente imagens e arquivos) em db é por questão de proteção. Para proteção, quero dizer, neste caso, o controle de acesso, a fim de proteger o material copywrited. Dessa forma, você pode controlar quem e quando viu / acessou um recurso específico e acompanhá-lo e, por meio de um procedimento de login, você também pode decidir quem tem o direito de acessar esses recursos.

    

Answer 3

Por que você alcança o tamanho do dx amxima (de 10gb) em R2?

• Crie um grupo de arquivos ew, use FILE SYSTEM STORE para armazenar os dados.
• Voila, terminou.

Os BLobs armazenados no sistema de arquivos NÃO CONTINUAM CONTRA O LIMITE DE TAMANHO.

Mais informações sobre esse recurso muito legal:

link